AppDomain or process per instance?

I would like to know whether I should use a process per instance or whether I should run multiple instances in a single process using AppDomains.

I have a server application which follows a design kind of like telnet. The user is always connected over TCP and the serve开发者_Go百科r keeps a full state of the client session which is presented on the workstation.

The software will need to support up to at least 500 concurrent connections, probably more. A typical installation will require somewhere between 3 and 7 instances of the application to be running continuously, although all but one instance will have just a few connections (they are for testing, reference environments, etc). In house, for development purposes, there will be a maximum of 40 environments with a maximum of 20 concurrent connections per environment. My target host environment will be 64bit Windows.

I know that IIS uses a model where it has just one process and multiple AppDomains, but I can also see advantages in having a process per instance.

Which should I use and why?

EDIT:

The different instances concern different versions of the same application which cannot be run in a single AppDomain together. Also, the different instances do not have to communicate with each other, only with a master service for management purposes.

---

To sum up:

1. You have a telnet like server application.
2. You will have multiple versions of this application running on the same machine.
3. The different instances do NOT need to communicate with each other; only with a common service.

Presumably each instance communicates over a different port

With those requirements I would never consider building out the same functionality that IIS has. Instead I would run them as completely separate applications.

BTW, you are incorrect stating that IIS only has 1 process with multiple app domains. IIS can spin up multiple processes for a single site. This is called a Web Garden. Further, IIS spins up at least one process for each Application Pool it has. You can see these as separate w3wp.exe processes executing on the IIS server.

The only benefit to running everything through a common process is if the host provides something of value that is common to everything. For example a logging interface or failure handling. This would be very complicated to write, set up, and maintain for little benefit.

Finally, the number of users is immaterial as that is going to be governed by resource usage of the application(s). This might mean network, memory, or even disk depending on exactly what functions your app performs.

---

well, you cant have process per user session since you plan for 500 of those. the same can be said for 500 appdomains. IIS uses an appdomain per Application , not user session, under a host process (app pool).

may i sugest you use a similar design? each instance in its app domain (40 max instacse you say?) each user handled by thread with no new app domain/process creaeted.(wont sacle as pointed) to support high number of users, maybe a load balancer can be used directing to a cluster of machines

---

It's pretty easy to structure your server so that you can decide this later, and, more likely, have a bit of a mix; some shared hosting with multiple app domains and some single hosting?

The complex bit isn't creating multiple app domains and running the same app multiple times. The complex bit is getting to the point where you can create a single app domain and host a single app. Once you can do that, scaling out to multiple app domains with either the same or different apps is easy.

I have an example server (here) that ships as part of my server framework that can operate in both ways, it hosts a single app domain on one port and spins up a per user app domain on a second port (I'm not suggesting that a per user app domain is what you need, just that it's at the opposite end of the scale to a single app domain per server).

There's also a new example which does the whole 'shadow copy, auto restart' thing that IIS does, this is a little more complex but I've written about it here and here. Again it's not too complex to do once you have the basic hosting in place.

Personally I tend to build all of that into a service and then simply run multiple copies if you want multiple server and then you can mix and match as you see fit and as profiling of the complete system suggests you should.

I guess, in summary, I'd say that you should design for the multiple app domain situation as you can always simply run a single app domain and multiple processes by configuring the server with a single app domain...