Separate application pools for ASP.net applications in IIS - asp.net

Question

I've read recommendations that we should create separate application pools for each asp.net application on our Win2008 server.
We have about 20 apps that would be on the same server. I know this would create 20 separate worker processes which seems very wasteful.
Is it good practice to create separate application pools for each application?

Answer 1

Reposted from ServerFault, "Why add additional application pools in IIS?"
AppPools can run as different identities, so you can restrict permissions this way.
You can assign a different identity to each app pool so that when you run task manager, you know which w3wp.exe is which.
You can recycle/restart one app pool without affecting the sites that are running in different app pools.
If you have a website that has a memory leak or generally misbehaves, you can place it in an app pool so it doesn't affect the other web sites
If you have a website that is very CPU-intensive (like resizing photos, for instance), you can place it in its own app pool and throttle its CPU utilization
If you have multiple websites that each have their own SQL database, you can use active directory authentication instead of storing usernames/passwords in web.config.

Answer 2

Separating apps in pools is a good thing to do when there's a reason, and there are a number of good reasons listed above. There are, however, good reasons not to separate apps into different pools, too.
Apps using the same access, .NET version, etc. will run more efficiently in a single pool and be more easily maintained. Most annoyingly, IIS will kill idle app pools, requiring the pool be recreated on each use. If you isolate infrequently used apps you'll impose an unnecessary startup cost on users. Combining these apps into a single pool will make for happier users when they don't pay the startup cost, happier servers when they don't give memory to multiple processes and CPU slices for them, and happier admins when they have to manage fewer app pools.

Answer 3

I used to have 58 .Net websites and 17 old classic ASP websites on the same IIS7.5 server using separate app pools for each site. I noticed that the IIS compression started failing intermittently, causing the style sheets to be corrupted about 5% of the time. Looking at the task manager on the server, I could see that the server was approaching it's 4GB ram limit- each w3wp.exe process was taking anything up to 100 MB memory depending on how much traffic the site was getting. I then moved all the websites into just 2 application pools (one for .net 4 websites and one for the old classic ASP sites) and the total memory used after doing that dropped from 3.8GB to just under 2.8GB - saving me over 1GB memory space on the server. After the change (and leaving the server running for a couple of hours to get back to normal levels of traffic), the w3wp processes were using 300MB for all the .net websites websites and 20MB for the classic ASP websites. I could re-enable IIS compression again without a problem.
Using separate APP pools is a great idea for many of the reasons mentioned by the other posts above, but it also in my experience causes a much higher memory overhead if you are hosting a fair number of websites on the same server.
I guess it's a trade-off between hardware restrictions and security whether you want to use separate app pools. It's a good idea if you have the resources to do it.

Answer 4

yes, it is a good idea even for 20 applications.
Security. Different app pools running under different accounts.
Isolation. One crashing app won't take down other apps.
Memory (if you are running 32bit). Each app pool will have its own address space. Thus you can address much more memory than a maximum of approximately 2.7GB of usable space for 1 process.
You may choose to periodically restart one not-so-well behaving app without affecting other applications.

Answer 5

If your apps are stable and don't use much memory, then I would say that it's fine to put them in the same app pool. App Pools give you isolation between your applications.

Answer 6

One main reason I consider when creating app pools is the process management. There are other reasons such as security etc.
When an IIS-hosted application crashes it takes down its host process as well. In previous versions of IIS this meant all web activity crashed together. With app pools you can isolate your applications from one another. If one has a memory leak and keeps crashing your other apps will continue to function.

Answer 7

The main benefit of creating different application pools is that you can provide each pool with other credentials. Your 20 applications may communicate with 20 different databases that all need another login. The best practice then is to run each application using a different service account.
I wouldn't worry too much about performance. Most time will probably be spent inside each web application, no matter what process each application is in.

Answer 8

This really depends on the applications, your security model, and how much you trust the applications.
Here are a few things that I always tell people to consider when working with application pools.
Use separate application pools if each application needs different access to system resources. (Can use multiple process accounts)
If an application is a resource hog, mission critical, or an "unknown", it is best to put it in to its own pool to isolate it from the rest of the system

Answer 9

We work as outside contractors for a large corporate client. We are not on-site, so we do not have connectivity to all of their systems. Sometimes during development it is necessary for me to debug an application directly on their development servers. To do that I must be able to attach to w3wp process. When I attach and start debugging, entire process stalls, which affects all of the applications that are in the same process/application pool.
By creating a dedicated application pool and moving my development there, I can easily debug without making anyone's life miserable.