Creating an app pool a month to limit the scope of issues

Question

I have about 360 sites running on a single app pool. Now I know we have a coding issue with one of those sites, were we have accidentally coded a memory leak. So what happens is the site runs, the memory leak starts and soon the app pool runs out of memory. Then slowly but surely, the rest of the 360 sites start going down like a domino affect. I understand that the root of the problem is some bad coding, which we'll fix, but instead of bringing down said 360 sites, I was thinking, we could create a new app-pool monthly that every site we create would go into that months app pool. First, that limit the scope of the issues to 5 - 20 sites and second if one site started having issues we wouldn't be bringing down all 360 sites.

Is there any issues to this thinking, possible ramifications? Thanks in Advance! Jeremiah

Answer 1

The purpose of application pools is to limit the risk of a single application taking down every sight on your box, so this is definitely recommended.

The "add one per month" part of your question doesn't make a whole lot of sense, once a site is in an application pool it will stay there forever, so this isn't necessary for your existing sites. Are you talking about future growth? If you update your question we can comment on that part further.

The downside is that each new application pool adds a bit of overhead (memory/cpu) to the server, so adding 360 of them probably isn't a good idea. Chunking the sites into (somehow related) groups is recommended.

A good place to start would be putting the "offending" applications into their own pool, and leaving the working applications in another - this will help stabilize things for most of your sites.

Answer 2

It would be better if you don't run all your applications in a single appPool. Here's what I feel is the right thing to do:

1. Identify your applications. Sort out the dynamic and static sites
2. You can have all static page Web sites in a single appPool say "staticappPool"
3. You will need to test/monitor all your dynamic applications by putting them in their own appPool first
4. The ones that are good can be hosted in a single appPool say "dynamicappPool". You will need to introduce more if the number of applications grow.
5. The ones that's giving issues you will need to debug the application

There is no hard limit on the number of appPools or number of applications per appPool you should have in IIS. But it is always better to have as less as appPools as possible. Creating a process in Windows is an expensive process. Also, it is important to note the number of appPools running concurrently.