Drawback to creating a separate IIS application pool for each website / application

Question

Currently, on our production IIS web farm, we host about 15 applications in a single App Pool (Default App Pool). There are two websites and about 13 virtual directories.

A colleague has recommended that we change our IIS configuration so each application is a separate App Pool (with identical settings).

Is there any drawback or potential issues to doing this? Is it possible that ASP.NET applications could have been built with the requirements that they are all within the same App Pool?

Answer 1

I doubt they were built with that requirement in mind unless they rely on shared memory for some reason. Otherwise, for the scenario described...

Pros (of separate app pool):

• process isolation (one crash doesn't bring down the others)
• less resource contention
• more memory available for in-proc sessions, cache

Cons:

• more processes, memory, and context switchces
• shared cache scenarios no longer available*

*I'm not sure how .NET segregates websites in the same app pool as it pertains to the HttpRuntime cache; for Sessions, "application uniqueness" (1) is determined by:

• The physical path on all servers (case sensitive)
• The machine key
• The instance id
• The approot

This is what prevents you from sharing sessions across different websites in the same app pool, for instance; but it might be easier to share cache data though. By and large, the discussion overlaps with the pros/cons of deploying a Web Garden for a specific application (2).

1)
http://support.microsoft.com/?id=325056
http://rodiniz.spaces.live.com/blog/cns!F2A56AAF89A7E43A!658.entry

2)
http://nicholas.piasecki.name/blog/2009/02/on-web-gardens-aspnet-and-iis-60/