Working with IIS 6.0 Application Pools – The Performance Tab

The Performance tab of IIS 6.0 application pool configuration properties contains settings that monitor the performance of the application pool and the worker processes running in it. These are the Performance configuration properties:

Shutdown worker processes after being idle for (time in minutes)
This setting limits the number of minutes that a worker process can remain idle before it will be shut down by the system.
Limit the kernel request queue (number of requests)
This setting limits the number of requests that can be queued for this application pool before 503 HTTP error messages are returned to users.
• Enable CPU monitoring
This setting activates CPU monitoring and enables the next three settings to be used.
• Maximum CPU use (percentage)
This setting specified the maximum CPU usage allowed before an action is taken.
• Refresh CPU usage number (in minutes)
This setting specifies the intervals at which the CPU usage should be checked.
• Action performed when CPU usage exceeds maximum CPU use
This setting specifies the action performed when the CPU usage is found to have exceeded the maximum CPU use. Two options are available:
1. Take No Action – IIS logs the CPU maximum usage event in the System event log but takes no corrective action.
2. Shutdown – IIS logs the event and requests that the application pool’s worker processes be recycled, based on the Shutdown Time Limit set on the Health tab.

• Maximum number of worker processes
This setting specifies the maximum number of worker processes that will be created to handle this application pool.

Notes on Shutting Down Idle Worker Processes
Although worker processes start on demand based on incoming requests and thus resources are allocated only when necessary, worker processes don’t free up the resources they use until they are shut down. In the default configuration, worker processes are shut down after they have been idle for 20 minutes. This ensures that any physical or virtual memory used by the worker process is made available to other processes running on the server, which is especially important if the server is busy.
Shutting down idle worker processes is a good idea in most instances, and if system resources are at a premium you might even want idle processes shut down sooner than 20 minutes. For example, on a moderately busy server with many configured sites and applications where there are intermittent resource issues, reducing the idle time-out could resolve the problems of resource availability.
Keep in mind though that shutting down idle worker processes can have unintended consequences. For example, on a dedicated server with ample memory and resources, shutting down idle worker processes clears cached components out of memory. These components must be reloaded into memory when the worker process starts and requires them, which might make the application seem unresponsive or sluggish.

Notes on Limiting Request Queues
When hundreds or thousands of new requests pour into an application pool’s request queue, the IIS server can become overloaded and overwhelmed. To prevent this from occurring, you can limit the length of the application pool request queue. Once a queue limit is set, IIS checks the queue size each time before adding a new request to the queue. If the queue limit has been reached, IIS rejects the request and sends the client an HTTP Error 503: Service Unavailable message.
Requests that are already queued remain queued even if you change the queue limit to a value that is less than the current queue length. The only consequence here would be that new requests wouldn’t be added to the queue until the current queue length is less than the queue limit.
The default limit for an application pool is 4000 requests. On a moderately sized server with a few application pools configured, this might be a good value. However, on a server with multiple CPUs and lots of RAM, this value might be too low. On a server with limited resources or many application pools configured, this value might be too high. Here you might want to use a formula of Memory Size in Megabytes x Number of CPUs x 10 divided by Number of Configured Application Pools to determine what the size of the average request queue should be. This is meant to be a guideline to give you a starting point for consideration and not an absolute rule. For example, on a server with two CPUs, 1024 MB of RAM, and twenty configured application pools, the size of the average request queue limit would be around 1,000 requests. You might have some application pools configured with request queue limits of 750 and others with request queue limits of 1,250. However, if the same server had only one configured application pool, you probably wouldn’t configure a request queue limit of 10,000.
Typically, you’ll want to set a value to at least 90 percent. However, to ensure that worker processes are recycled only when they’re blocking other processes, you should set the value to 100 percent.

Notes on CPU Monitoring
Typically, you’ll want to set a value to at least 90 percent. However, to ensure that worker processes are recycled only when they’re blocking other processes, you should set the value to 100 percent.
In most cases you won’t want to check the CPU usage more frequently than every five minutes. If you monitor CPU usage more frequently, you might waste resources that could be better used by other processes.

Notes on Configuring Multiple Worker Processes for Application Pools
Multiple worker processes running in their own context can share responsibility for handling requests for an application pool. This configuration setting is referred to as a Web Garden. When you define a Web Garden, each new request is assigned to a worker process according to the round-robin load balancing technique.
If a single application is placed in an application pool serviced by multiple worker processes, any and all worker processes available will handle requests queued for the application. This is a multiple-worker-process-to-single-application configuration, and it is best used when you want to improve the application’s request handling performance and reduce any possible contention for resources with other applications. In this care the application might have heavy usage during peak periods and moderate-to-heavy usage during other times, or individuals using the application might have specific performance expectations that must be met.
If multiple applications are placed in an application pool serviced by multiple worker processes, any and all worker processes available handle the requests queued for any applicable application. This is a multiple-worker-process-to-multiple-application configuration, and it is best used when you want to improve request handling performance and reduce resource contention for multiple applications but don’t want to dedicate resources to any single application. In this case the various applications in the application pool might have different peak usage periods or might have varying resource needs.
It’s important to note that worker processes aren’t started automatically and don’t use resources until they are needed. Rather, they are started as necessary to meet the demand based on incoming requests. For example, if you configure a maximum of five worker processes for an application pool, there may be at any given time from zero to five worker processes running in support of applications placed in that application pool.
You also need to keep in mind that when you assign multiple worker processes to a busy application pool that each worker process sues server resources when it’s started and might affect the performance or applications in other application pools. Adding worker processes won’t resolve latency issues due to network communications or bandwidth, and it can reduce the time it takes to process requests only if those requests were queued and waiting and not being actively processed. A poorly engineered application will still respond poorly, and at some point you’d need to look at optimizing the application code for efficiency and timeliness.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s