views:

230

answers:

6

On an server running multiple ASP.NET sites, is it better to use one application pool per site or for sites to share a single application pool? What are the advantages or disadvantages inherent to each setup? Or is there a hard and fast rule here?

A: 

It would depend a lot on if certain sites need more reliability than others, what your expected load per site is, etc.

Sharing a pool will be more efficient in general, but a single misbehaving application can more rapidly cause problems for other sites. Additionally you can recycle or update separate app pools separately which may make maintenance schedules easier.

Jason Coyne
A: 

There's no hard and fast rule. I tend to use one app pool per site (and IIS7 even defaults to creating one per site) because I like to play it safe in case I have a memory leak in one site/pool, I don't want it affecting and taking down other sites. But I've also got some servers where 100 sites share a single pool without issue. So, as always, it depends.

John Sheehan
+2  A: 

One of the advantages of separate AppPools is that in the event that you need to recycle the AppPool you can do so for one site without affecting the performance (or caching) of the others.

Andrew Hare
+3  A: 

This really depends on what the requirements are of the site, as well as your concern regarding risks.

When two applications run inside the same application pool they have the same security level, so there is a security concern here for some as in theory each could have access to files of the other. Also, if one site starts having issues and using memory it could cause recycles or freezes that could impact both.

Although there is not a "hard and fast" rule to this, some of the things that I consider and that cause "automatic" decisions for me are the following.

  • Is the application mission critical? (If so, separate app pool)
  • Is this a third party application? (If so, and unsure of what all it does, separate app pool)
  • Will this application see major spikes in activity? (If so, it might be best to isolate)

There is a lot out there, but the keys are isolation and ability to troubleshoot single applications. Here is a Microsoft article that touches on it a bit as well.

Mitchel Sellers
A: 

I would strongy prefer single application - single application pool - unles you have performance concerns. An exception in background thread (once someone starts playing async) can bring down the whole app pool. And unless you have automatic recycling enabled this may cause lot of trouble.

Rashack
+2  A: 

One critical rule to remember:

DO NOT put .Net 1.1 and .Net 2.0 applications in the same application pool. It will mess things up really fast.

Dillie-O