Application Pool Configuration in IIS 6.0

Updated: February 19, 2010

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This topic provides some best practices recommendations for configuring IIS application pools on your IIS 6.0 Web server. Application pools enable specific configuration settings to be applied to groups of applications, and the worker processes that service those applications. All Web sites and virtual directories must be assigned to an application pool. Configuring application pools appropriately can increase service availability on the server as application pools isolate sites and applications from other sites and applications.

Planning Application Pool Configuration

You can configure application pools to optimize performance for your server and organization. The ideal configuration for your environment depends on many factors. These include hardware and network configuration, the number of Web sites that are running on the server, and the applications on those sites. The guidance provided here is intended to highlight points to consider instead of the specific settings for your particular environment. For example, you may want to isolate sites or applications by technology, such as ASP.NET, or by business segment, such as Human Resources or Finance. You may also want to isolate sites and applications by business priority or by specific application. You can configure application pools using one or more of these categories, or define categories to support your specific business needs.

Application Pools and Service Availability

How you configure application pools on your server directly affects the availability of the WWW service on your IIS server. For example, if there are two Web sites that are running in a single application pool, the same worker process (W3wp.exe) handles requests for both the sites. If one of the sites experiences a fatal error, the process stops processing requests for both the sites in the application pool. To avoid this, configure a separate application pool for each site so that errors in one are isolated from the other sites on the server.

As a best practice, you should configure application pools to isolate mission critical applications from other applications on the server. This can also result in better performance for critical applications as the computer continues to process requests for the critical application, even if there are problems in other application pools. Requests for other applications or sites are handled by the process in a separate, isolated application pool.

In some cases, administrators prefer to configure each site on the server to run in its own application pool. This is a supported configuration. However, exceeding about 60 application pools that use unique identities on a server requires special configuration, and may cause a decrease in performance because of high utilization of hardware resources. If it is a priority to configure more than 60 application pools but hardware limitations prevent doing this, you could also add another IIS server to your environment and then run some sites and applications on the additional server.

Advanced Configurations

If you are configuring your application pools with unique identities, depending on the applications and memory resources on your server, you will reach a limit of about 60 application pools. There are finite limits to some system resources that get allocated with each new logon session. This means that 60 processes can run concurrently as distinct accounts. IIS 6.0 supports running these processes in a single shared workstation and desktop, at a cost of sharing a single encapsulation of a user session among all parties.

To scale beyond 60 application pools and to share a single desktop, change the value of the registry HKey_Local_Machine\System\CurrentControlSet\Services\W3SVC\Parameters\UseSharedWPDesktop subkey to 1 (the data type is DWORD). After changing this registry entry, you can scale to hundreds of application pools and hundreds of concurrently running worker processes.

If IIS starts more worker processes than can be supported, or if the server is running out of resources, you can set a maximum number of concurrent worker processes. By using the IIS 6.0 and HTTP.sys architecture, and with a request load distributed across many application pools, IIS will try to start more worker processes than the server can sustain without running out of memory or CPU resources. The DemandStartThreshold Metabase property (also named concurrent process gating), when set to a value less than the default, applies a hard limit to the number of IIS worker processes that can run concurrently. If the hard limit is exceeded, HTTP.sys returns an HTTP 503 error (Service Unavailable).