36

What are pros and cons of having dedicated application pools over keeping web applications in one default app pool?

stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
GrZeCh
  • 2,332
  • 8
  • 29
  • 38
  • It might be a good idea for you to clarify whether you are talking about interactive applications or web sites delivering content. Also how many apps/websites you are talking about. The answer can be quite different depending on this info. – AnthonyWJones Oct 21 '08 at 20:26

5 Answers5

25

Pros:

  • Applications are isolated from each other, unless IIS goes with it, an app pool locking will only take out applications in that pool
  • Ability to run applications under different ASP.NET runtimes, one pool for 1.1 another for 2.0 if needed
  • Ability to have different app pool settings for more or less critical applications. For example a corporate website in ASP.NET might want to have the shut down after __ minutes of inactivity bumped up, to prevent unloading because response is critical. Other sites might not need it.
  • Can secure pools from each other in regards to file access, great for third party, or untrusted applications as they can run under a very restrictive user account.

Cons:

  • Each application pool has its own bank of memory and its own process, therefore CAN use more resources
  • Some find it hard to debug the application as you have multiple processes
Mitchel Sellers
  • 62,228
  • 14
  • 110
  • 173
18

The primary reason for combining sites in app pools is to conserve memory. There's a large memory overhead in running several w3wp.exe processes. If you have no specific reason for splitting them up, it's better to keep them together.

Mark S. Rasmussen
  • 34,696
  • 4
  • 39
  • 58
  • 3
    PLEASE add a comment when you vote an answer down. The person who asked the question liked this response. Is the answer wrong? Why? – DOK Oct 21 '08 at 20:35
  • +1 for this. It's not a blanket answer. I have a multi-layered app running next to a demo site. The demo site's service and content sites are all in the same app pool, whereas production is seperated. Makes sense to do either/both as it's a very simple way to allocate resources. – Gats Mar 30 '13 at 10:02
  • For local development it's fine to have one app pool (for easy debug, less memory consume), but for staging/production we use dedicated pools for each website – igorGIS Sep 16 '14 at 08:23
16

Dedicated app pools typically will keep problems occurring in one site from effecting the others. If you share app pools across sites, you could bring down all sites on the box when an error condition exists for only a specific site (or app pool).

Also, if you are mixing versions of ASP.Net on the same web server, you will need different app pools per ASP.Net version at a minimum, or do it per website.

I can't think of a good reason not to separate app pools, it is so easy to do.

JasonS
  • 23,480
  • 9
  • 41
  • 46
6

I agree with Jason.

Also, you can designate different users (such as a Windows account) for different app pools. That enables setting up those users with different permissions in the database. That helps enhance security, and enables tracking which website/user is hitting the database, useful when tracing database performance issues.

DOK
  • 32,337
  • 7
  • 60
  • 92
  • 2
    In fact, with [application pool identities](https://blogs.iis.net/webdevelopertips/tip-98-did-you-know-the-default-application-pool-identity-in-iis-7-5-windows-7-changed-from-networkservice-to-apppoolidentity), you can grant DB permission *to one specific application pool* without the need for additional Windows accounts. This also protects your customer's data: If one web application gets pwned, the attacker won't get access to the other databases. – Heinzi Oct 10 '16 at 12:28
1

If you have separate apppools then you pay a penalty in the initial load time of the first person to visit your site and spin back up the apppool after it recycles.

For example let's say overnight no-one hits your server, IIS will spin down (default 20mins I believe). The first person to visit the server will suffer a delay until the your application has been loaded back into memory.

Depending on how you deploy your site (e.g. release mode etc..) this will either not be a problem or could be annoying.

This is why we are looking into moving to a single apppool/server rather than 1 for each site.

Markive
  • 2,350
  • 2
  • 23
  • 26