Note
The following counters will also help you identify
bottlenecks:[This is preliminary documentation and subject to change]
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.
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:
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 Segments Sent/sec Server\ Bytes Total/sec |
For more information on counters related to IIS, performance, and hardware performance, see the Counters Reference and Measuring Hardware Performance.
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: