What are pros and cons of having dedicated application pools over keeping web applications in one default app pool?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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
Method 2
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.
Method 3
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.
Method 4
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.
Method 5
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0