[This is preliminary documentation and subject to change]

# Processor Utilization

This section focuses on processor aspects of performance and makes recommendations for upgrades, based on feedback from performance monitoring tests.

## Identifying Processor Bottlenecks

The CPU does the actual processing of instructions received by the computer. Information moves between the various components of the computer, such as the CPU, hard disk, and RAM, depending on the clock speed of the CPU and the size of the data bus the CPU uses to move the information. Faster clock speeds mean that more trips are made back and forth by the data bus during the same time interval. Clock speeds are usually expressed as megahertz (MHz). The data bus can carry 16, 32, or 64 bits of data on each trip, depending on the bus size. (How much data is carried is also a function of the operating system used and what transfer rate the application is based on.)

Processor bottlenecks are characterized by very high CPU % Utilization numbers while the network adapter card remains well below capacity. If CPU % utilization is high, you can:

- Upgrade the CPU.
- Add additional CPUs to the same computer.
- Replicate the site on another computer and distribute traffic across both computers.
- Move processor-intensive applications such as database applications to another computer.

## Throttling Processes Overview

You can limit the percentage of time the CPU spends processing out-of-process WAM, ISAPI, and CGI applications for individual Web sites by enabling process throttling. Limiting access to the CPU is useful if you host multiple sites on one computer and you are concerned about out-of-process applications on one site using all of the CPU capacity, thereby preventing other sites from using it.

Note For instructions on how to set up process throttling, see Throttling Processes.

If a restricted site's out-of-process applications use more than the assigned percentage of processor time during a specified time interval, the event is logged and consequences occur based on the amount of overrun of the assigned percentage. The consequences are:

- Level 1 An event is written to the Windows Whistler Event Log when the total processor use over the specified time period exceeds the limit.
- Level 2 If the processor use exceeds 150 percent of the limit, an event is written to the Event Log, and all the out-of-process applications on that Web site have their CPU priority set to Idle.
- Level 3 If the processor use exceeds 200 percent of the limit, an event is written to the Event Log, and all the out-of-process applications on that Web site are stopped.

Once a site has reached a Level 2 or Level 3 consequence, the consequence remains in effect until the next time interval. For example, if a site's out-of-process applications are restricted to 10 percent of the CPU processing time during a 24-hour interval, the site's applications should be using the CPU for only 2.4 hours out of 24. If the site uses the CPU longer than 2.4 hours, but less than 3.6 hours, the only consequence is that an event is written to the Event Log. Once the site uses the CPU for more than 3.6 hours, all out-of-process applications on the site are set to Idle. If the server is not very busy and the applications continue to use processor time, eventually reaching 4.8 hours of use during the 24-hour interval, the out-of-process applications are stopped on the Web site.

Process accounting is reset at the end of the 24-hour period and the site returns to normal functioning. Administrators can return a site to normal functioning sooner by changing the percentage set for a Web site, or by stopping and restarting the site. Web site Operators do not have permission to change this setting. For information on setting process restrictions, see Throttling Processes. For information on process accounting, see About Logging Site Activity. For information on how to enable an additional consequence level and how to change process throttling time intervals by using scripts and the metabase, see Using IIS Admin Objects.

If you enable process throttling, then you should probably lower the CGI timeout interval. By default, the interval is set to 5 minutes. If the CGI applications fails, the thread is not released until the timeout value is reached. The time between failure and when the thread is finally released is counted as time that the application is using the processor. The CGI timeout in IIS 6.0 is the total amount of time a CGI application is given to complete, not the time until I/O must occur. For instructions on how to change the CGI timeout, see Caching Applications.

Related Topics

- For a list of all timeout values that can be set by IIS, see Timeouts Reference.

© 1997-2001 Microsoft Corporation. All rights reserved.