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.

Answer 1

Besides the configuration time and (maybe) more memory requirements there is no down side to using more than one App Pool.

(Just to be clear... the memory needed will vary depending on many factors -- but there is a way where 15 apps in one pool use more memory than 15 apps in 15 pools. If each app does not need much memory and the apps are used at different times and infrequently.)

Answer 2

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/