Maintaining Application Health and Performance

Maintaining the health and performance of Web applications is an important part of your job as a Web administrator. Fortunately, IIS has many built-in functions to make this task easier, including:

• CPU monitoring and automated shutdown of runaway worker processes

• Worker process failure detection and recovery

• Request queue limiting to prevent server flooding

• Idle worker process shutdown to recover resources

Each of these tasks is discussed in the sections that follow.

Configuring CPU Monitoring

Typically, when a process consistently uses a high percentage of CPU time, there’s a problem with the process. The process might have failed or might be running rampant on the system. You can configure IIS to monitor CPU usage and perform either of the following CPU performance monitoring options:

• Take No Action IIS logs the CPU maximum usage event in the System event log but takes no corrective action.

• Shutdown IIS logs the event and requests that the application pool’s worker processes be recycled, based on the Shutdown Time Limit, set in the Health tab.

To configure IIS to monitor the CPU usage of worker processes, follow these steps:

1. In the IIS snap-in, expand Application Pools, right-click the application pool that you want to configure, and then select Properties.

2. Select the Performance tab as shown in Figure 6-6 on the following page.

3. To allow CPU monitoring, select the Enable CPU Monitoring check box.

4. Use the Maximum CPU Use (Percentage) field to set the percentage of CPU usage that triggers event logging, worker process recycling, or both.

   Tip

   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.

5. Use the Refresh CPU Usage Numbers (In Minutes) field to specify how often IIS checks the CPU usage.

   Caution

   In most cases you won’t want to check the CPU usage more frequently than every five minutes. If you monitor the CPU usage more frequently, you might waste resources that could be better used by other processes.

   
   Figure 6-6: Configure CPU monitoring to ensure that runaway processes are reported or terminated.

6. If you want to log the CPU usage event but not have IIS attempt to shut down worker processes, set the Action Performed… drop-down list to No Action.

7. If you want to log the CPU usage event and have IIS attempt to shut down the worker processes used by the application pool, set the Action Performed… drop-down list to Shutdown.

8. Click OK.

Configuring Failure Detection and Recovery

You can configure application pools to monitor the health of their worker processes. This monitoring includes processes that detect worker process failure and then take action to recover or prevent further problems on the server.

Central to health monitoring is process pinging. With process pinging, IIS periodically checks to see if worker processes are responsive. This means that the WWW Service (Svchost.exe) sends a ping request at a specified interval to each worker process (W3wp.exe). If a worker process fails to respond to the ping request, either because it doesn’t have additional threads available for processing incoming requests or because it’s hung up, the WWW service flags the worker process as unhealthy. If the worker process is in an idle but unresponsive state, the WWW service terminates it immediately and a replacement worker process is created. Otherwise, the worker process is marked for recycling as discussed previously in this chapter.

You can also configure application pools for rapid-fail protection. When rapid- fail protection is enabled, the WWW service stops an application pool if there are a certain number of worker process failures in a specified time period. In the standard configuration, five worker process failures within a five-minute interval trigger rapid-fail protection.

To configure health monitoring, complete the following steps:

1. In the IIS snap-in, expand Application Pools, right-click the application pool that you want to configure, and then select Properties.

2. Select the Health tab as shown in Figure 6-7.

   
   Figure 6-7: Pinging and rapid-fail protection are important monitoring techniques for detecting and recovering from problems.

3. To enable process pinging, select the Enable Pinging check box and then use the field provided to set the ping interval in seconds. Here are some guidelines:

   • For low priority applications or applications that are used infrequently, you might want to set an interval of several minutes. This ensures that the responsiveness of applications is checked only as often as necessary.

   • On a busy server or a server with many configured applications, you might want to set a longer interval than usual. This will reduce resource usage due to ping requests.

   • For high-priority applications where it’s critical that applications run and be responsive, you might want to set an interval of one minute (60 seconds) or less. This ensures that the responsiveness of applications is checked frequently.

4. To prevent idle processes from being shut down after a specified period of time, on the Performance tab, clear the Shutdown Worker Processes After Being Idle For check box.

5. Click OK.

   Note

   Keep in mind that these monitoring techniques aren’t perfect, but they’re helpful. They won’t detect all types of failures. For instance, they won’t detect problems with the application code, such as conditions that cause the application to return an internal error, and they won’t detect a nonblocking error state, such as when the worker process can allocate new threads but is unable to process current threads.

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’re shut down. In a standard configuration, worker processes are shut down after they’ve 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.

Tip

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 with resource availability.

Caution

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.

To configure the idle process shutdown time, follow these steps:

1. In the IIS snap-in, expand Application Pools, right-click the application pool that you want to configure, and then select Properties.

2. Select the Performance tab as shown in Figure 6-8.

   
   Figure 6-8: Set the idle time-out to meet your application environment’s needs.

3. To allow idle processes to be shut down after a specified period of time, select the Shutdown Worker Processes After Being Idle For check box and then use the field provided to set the shutdown time in minutes.

4. To prevent idle processes from being shut down after a specified period of time, clear the Shutdown Worker Processes After Being Idle For check box.

5. Click OK.

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.

Real World

The standard limit for the default application pool is 1000 requests. On a moderately sized server with few applications 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 applications configured, this value might be too high. Here, you might want to use a formula of Memory Size in Megabytes Number of CPUs 10 / Number of Configured Applications 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, 512 MB of RAM, and eight configured applications, the size of the average request queue limit would be around 1280 requests. You might have some applications configured with request queue limits of 1000 and others with request queue limits of 1500. However, if the same server had only one configured application, you probably wouldn’t want to configure a request queue limit of 10,000.

To configure the request queue limit, follow these steps:

1. In the IIS snap-in, expand Application Pools, right-click the application pool that you want to configure, and then select Properties.

2. Select the Performance tab as shown previously in Figure 6-8.

3. To specify and enforce a request queue limit, select the Limit The Kernel Request Queue check box and then use the field provided to specify the request limit.

4. Click OK.

   Note

   Requests that are already queued remain queued even if you change the queue limit to a value that’s 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.