IIS 7.0 : Performance and Tuning - Processor

What Causes CPU Pressure?

If there was an easy answer to the question of what causes CPU pressure, an administrator’s job would be a lot easier. Let’s look at a list of common items that cause pressure:

• Poorly written applications

• Memory-intensive services

• Servers not sized to support the applications

• Too many processes on the server

• Servers not having enough RAM

As you can see by the preceding list, a variety of issues can cause CPU pressure.

Throttling

Throttling an application or process is one way of keeping server resources available and not allowing the server to become unresponsive. The term throttling means limiting the amount of server resources a particular process or resource can use. For example, IIS 7.0 offers various ways to throttle resources—from bandwidth to connection time-outs and limits. If your server hosts multiple Web sites, you can throttle the number of connections one Web site receives. This would help keep it from using too many connections or server resources and also prevent other Web sites hosted on the server from being affected. Figure 1 shows the available options in IIS 7.0 that you can throttle. This can be done a per–Web site basis.

Figure 1. Per–Web site limits available in IIS 7.0.

IIS 7.0 offers several ways using application pool limits to throttle resources. You can set limits on worker process CPU settings, Rapid Fail Protection, Recycling, and several settings in the Process model section located in application pool settings.

Caching provides one of the better ways to enhance your application’s performance. There are also ways to throttle how much of the server resources are used. Locking down how much RAM caching is allowed to use can impact the performance gains your application experiences.

You can use application pool options to help lower CPU usage so that your higher impact sites have resources available. This is one example of how you could control resources on your server and maximize application performance.

CPU Counters to Monitor

See Table 1 for a list of common counters that help identify which processes and how much of the server resources are being used when your IIS 7.0 server is experiencing high CPU conditions.

Table 1. CPU Counters to Measure

Counter Name	Description
Processor(_Total)\% Interrupt Time	The time the processor spends receiving and servicing hardware interrupts during sample intervals. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards, and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the average busy time as a percentage of the sample time.
Processor(_Total)\% Privileged Time	The time the processor spends receiving and servicing hardware interrupts during sample intervals. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards, and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the average busy time as a percentage of the sample time.
Processor(_Total)\% Processor Time	The percentage of elapsed time that the processor spends to execute a non-idle thread. It is calculated by measuring the percentage of time that the processor spends executing the idle thread and then subtracting that value from 100%. (Each processor has an idle thread that consumes cycles when no other threads are ready to run.) This counter is the primary indicator of processor activity and displays the average percentage of busy time observed during the sample interval. It should be noted that the accounting calculation of whether or not the processor is idle is performed at an internal sampling interval of the system clock (10 ms). On today’s fast processors, % Processor Time can therefore underestimate the processor utilization, as the processor may be spending a lot of time servicing threads between the system clock sampling intervals. Workload-based timer applications are one example of applications that are more likely to be measured inaccurately, as timers are signaled just after the sample is taken.
Processor(_Total)\% User Time	The percentage of elapsed time the processor spends in user mode. User mode is a restricted processing mode designed for applications, environment subsystems, and integral subsystems. The alternative, privileged (kernel) mode, is designed for operating system components, and it allows direct access to hardware and all memory. The operating system switches application threads to privileged mode to access operating system services. This counter displays the average busy time as a percentage of the sample time.
System\Context Switches/sec	The combined rate at which all processors on the computer are switched from one thread to another. Context switches occur when a running thread voluntarily relinquishes the processor, is preempted by a higher priority ready thread, or switches between user-mode and privileged (kernel) mode to use an Executive or subsystem service. It is the sum of Thread\\Context Switches/sec for all threads running on all processors in the computer and is measured in numbers of switches. There are context switch counters on the System and Thread objects. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.
System\System Calls/sec	The combined rate of calls to operating system service routines by all processes running on the computer. These routines perform all of the basic scheduling and synchronization of activities on the computer and provide access to nongraphic devices, memory management, and namespace management. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.

Reliability and Performance Monitor counters can help you establish a baseline for your server and can help you understand the number of resources used during normal and peak times. When an issue arises, you can use the server’s baseline information and then compare the statistics collected to help identify the issue.

Using Reliability and Performance Monitor counters provides a lot of information. When used effectively, using these counters will help isolate and resolve a performance problem.

Impact of Constraints

Constraining the CPU resources on a server can impact how your application performs. This applies only when you are putting constraints on your application. When you do so, it impacts performance—one application frees up resources for another application.

Countermeasures

One example of how IIS 7.0 can help counter high CPU usage is by implementing Web gardens. Web gardens are an available feature on worker processes that help spread the workload across multiple processes. See Figure 2.

Figure 2. Maximum worker processes setting in IIS 7.0.

One thing to keep in mind is that Web gardens do not work on applications requiring stateful sessions. What does that mean? If you have a caching application, the variables will be cached in each application pool process and will not be shared among other processes. The reason for this is that each process has its own copy of the application state, so values are independent of other worker processes and would not match across other processes in the Web garden.

Consider this example of when to use Web gardens. Steve at Contoso Ltd. has an application that is hitting the 2 GB x86 process limit and is crashing. The application does not use session state, so it is a candidate for enabling Web gardens. After enabling Web gardens, Steve is able to spread the application load across multiple worker processes, preventing the application from crashing.

Let’s take a look at another example from Steve at Contoso Ltd. He also has a database process that experiences latency. From time to time, this causes the application pool to crash. To help with performance and tuning of the application, Steve adds processes to give the application multiple processes accessing the resource (in this case, it’s a database).