[This is preliminary documentation and subject to change]

# About Performance Monitoring

Performance monitoring is the process of capturing and analyzing the performance data that applications, services, and drivers provide to determine system bottlenecks and fine-tune system and application performance. You can monitor performance by writing a program that calls the Performance Monitor registry interface or the Performance Data Helper (PDH) interface, or by using applications provided with Windows Whistler. The method you choose will typically depend on how much data you want to monitor and what kind of analysis you want to perform on the data.

Once you have configured your IIS server, you can review the design by tracking system performance. You can use the System Monitor tool and the Performance Logs and Alerts tool, which ship with Windows Whistler, to log actual workload statistics for any system objects you want to review. Then you can analyze the logging data to determine if configuration adjustments are required to ensure that messages and alerts are processed efficiently.

You can customize the logging process to track different types of information. You choose the system objects you want to monitor and then set counters to track their performance. To fine-tune the tracking and increase administrator response time to events, you can set the Performance Logs and Alerts tool to generate an alert whenever a counter exceeds or drops below a measurement you specify. Once the data is generated, you can export it to spreadsheets or databases for further review and analysis.

- Troubleshooting Performance Bottlenecks
- Response Time and Resource Utilization

## Troubleshooting Performance Bottlenecks

A processor bottleneck develops when threads of a process require more processor cycles than are available. Long processor queues can build up and system response suffers. The two most common causes of processor bottlenecks are CPU-bound programs and drivers or subsystem components (typically disk or network components) that generate excessive interrupts.

Analysis of your monitoring data may reveal problems such as excessive demand on certain resources resulting in bottlenecks. Demand may become extreme enough to cause resource bottlenecks for the following reasons:

- Resources are insufficient and additional or upgraded components are required.
- Resources are not sharing workloads evenly and need to be balanced.
- A resource is malfunctioning and needs to be replaced.
- A program is monopolizing a particular resource; this may require substituting another program, having a developer rewrite the program, adding or upgrading resources, or running the program during periods of low demand.
- A resource is incorrectly configured and configuration settings should be changed.

To determine whether a processor bottleneck exists due to high levels of demand for processor time and high CPU percentage, check the value of the System\ Processor Queue Length counter. A queue of two or more items indicates a bottleneck. If more than a few program processes are contending for most of the processor's time, installing a faster processor will improve throughput. An additional processor can help if you are running multithreaded processes, but be aware that scaling to additional processors is dependent on application design and may have limited benefits.

To determine whether interrupt activity is causing a bottleneck, watch the values of the Processor\ Interrupts/sec counter, which measures the rate of service requests from input/output (I/O) devices. If this counter value increases dramatically without a corresponding increase in system activity, it can indicate a hardware problem.

You can also monitor Processor\ % Interrupt Time for an indirect indicator of the activity of disk drivers, network adapters, and other devices that generate interrupts.

Note The following counters will also help you identify bottlenecks:

Where | Counters
--- | ---
In memory resources: | Memory\Available Bytes Memory\Pages/sec Memory\Pool Nonpaged Bytes Memory\Pool Paged Bytes
In disk resources: | PhysicalDisk\ % Disk Time and % Idle Time PhysicalDisk\ Disk Reads/sec and Disk Writes/sec PhysicalDisk\ Avg. Disk Queue Length LogicalDisk\ % Free Space Note Be sure to monitor memory counters to determine whether excessive paging is putting a strain on the disk.
In processor resources: | Processor\ Interrupts/sec Processor\ % Processor Time Process(inetinfo)\ % Processor Time Process(w3svc)\ % Processor Time System\Context Switches/sec System\ Processor Queue Length
In network resources: | Network Interface\ Bytes Total/sec Bytes Sent/sec Bytes Received/sec Segments Sent/sec Frames Sent/sec Frames Received/sec Server\ Bytes Total/sec Bytes Received/sec Bytes Sent/sec

For more information on counters related to IIS, performance, and hardware performance, see the Counters Reference and Measuring Hardware Performance.

## Response Time and Resource Utilization

Response time is the time (often an average) that elapses between the issue of a request and the return of the data requested (or notification of inability to provide it). Response time is a measure of your server and Web site performance. When your server is under load, requests may take longer to complete than if the server were unloaded. For user requests, this can result in increased response time for clients. If the server is under an excessive load, users may perceive the server as slow or unresponsive.

The ability for IIS to handle heavy loads and maintain good response time is primarily dependent on the performance and scalability of your applications. Factors like network latency and database processing also affect response time, but those factors may be out of your control. You can improve response time through better application design and by using some of the IIS features designed to manage your server resources so heavy loads do not cause bottlenecks or overload the Web service. By monitoring your server performance, you can determine if poor response time is actually a symptom of a bigger problem on the server side (for example a poorly-designed application, poor resource utilization, or improper cache settings) or if the problem is network latency. Before making any changes to your system, use the System Monitor tool to establish a performance baseline about your system and to monitor memory, CPU utilization, and disk space to make certain your system has enough of these resources. You can also use System Monitor to see how often your system reads from disk. If your system is accessing the disk often, see Disk Optimization for ways to decrease hard-disk bottlenecks. For more information on monitoring your hardware, see Measuring Hardware Performance. For more information on the System Monitor tool, see Tools Used to Monitor Performance.

If, after monitoring your hardware, you determine that your system has enough resources, monitor and tune your applications. For more information, see Monitoring Your Web Applications. If you need to redesign an application to improve response time, consider replacing Visual Basic applications with C or C++ applications and test your applications under heavy loads (twice the expected load) to see how they perform. You can load test and measure response time with Microsoft's Web Application Stress Tool (WAST) and the Application Center Test (ACT) tool. For more information, see Tools Used to Monitor Performance.

If, after monitoring your hardware, you determine that system resources are causing problems consider adding resources and enabling the following features to help control resources. Note that most of these features require IIS to be in dedicated application mode:

- Application Pool Queue Length Limits: Prevents too many requests from queuing up and overloading the system.
- CPU Accounting: Includes several features that control system resources used by a process or group of processes.
- Throttling Bandwidth: Controls the maximum amount of bandwidth dedicated to Internet traffic on a server.
- Dedicated Application Mode: Forces all application code to run in an isolated environment. This design removes some of the existing bottlenecks and points of contention and cuts down on the need to restart your server.
- Process Recycling: Allows you to configure IIS to periodically restart worker processes in an application pool for better process management.
- Web Gardens: Creates an application pool that has multiple worker processes serving the requests routed to that pool, which reduces lock contention.

© 1997-2001 Microsoft Corporation. All rights reserved.