A great many documents, blogs and references exist on IIS which cover it comprehensively. This article simply serves to discuss one aspect – the application pool.
When configuring IIS in an environment that will contain many websites, there are a few important considerations:
– Will each site potentially run different versions of .NET? Sites with different frameworks should not share the same app pool. This will cause a conflict and they will not be functional.
– Is it a large web application that requires many resources? If yes, you may also want to consider creating it’s own app pool, which allows you to manage detailed information regarding how the server prioritizes the site.
The first tab for the app pool properties displays information regarding memory resource usage. If you have multiple sites on a server which are hit very often and would like to force the amount of memory each one uses, you can create an app pool for each and manage it here.
Or if it will be split evenly among various sites, you can create “groups” of app pools with assigned memory and IIS will allocate among children accordingly.
You can also force the worker process to automatically free up memory after specified interval and/or at different times of the day.
The performance tab allows for CPU resource management. Certain sites may have functions that, left unchecked or still under development, can cause excessive CPU load and affect other processes running on the same server.
Max CPU usage can be assigned here setup in conjunction with events to trigger when these scenarios occur.
A remote exploit or overflow attempt of your server can also be secured here by limiting the maximum number of kernel requests.
Idle timeout can help free up CPU for a site that is not very active. Legacy sites or informational areas which are rarely visited are still using a fraction of the CPU usage, and setting an idle timeout can help release some of those resources.
The health tab can help you diagnose potential issues with your site or application. By forcing certain restrictions such as maximum failures and/or maximum failures within a specific time period, as well as enabling pinging, you can check for periods of down time or help identify timeout issues a specific web service may be experiencing.
This tab works well in conjunction with third party testing tools used to benchmark and stress test your site, application or service.
Depending on the size and nature of your infrastructure, you may want to configure certain application pools to run under different credentials. For highly security conscious people this can theoretically reduce the likelihood of certain privilege escalation techniques that may be executed in the event of a remote application pool exploit.
Hope the above information was helpful. This was a condensed version based on a similar article I read on Windows Networking. See reference below for full article.