Performance Monitoring | IIS 6 Administration

So far in this chapter, I’ve talked about how to tune IIS by using IIS Manager properties sheets, editing the Registry, and modifying various metabase properties. Unfortunately, performance tuning is more an art than a science, and changing such settings arbitrarily can sometimes end up making things worse instead of better. The solution is to carefully monitor the performance of your server to see what effect such changes have. I’ll conclude this chapter by looking at performance monitoring and how to do it, focusing particularly on monitoring the performance of IIS 6 machines.

Tools for Performance Monitoring

The main tools for performance monitoring on the Windows Server 2003 platform are two MMC snap-ins:

System Monitor Previously known as Performance Monitor on the Windows NT platform, this tool can be used to monitor different aspects of your server’s performance by collecting real-time data and displaying it graphically in the form of charts, generating reports, and generating alerts when specified conditions arise.
Performance Logs and Alerts This tool can be used for collecting performance information and saving it in logs that can be displayed and analyzed afterwards using System Monitor or exported to a spreadsheet or database program for analysis and reporting.

To make life simple for the administrator, Windows Server 2003 combines both of these snap-ins into a single MMC console called Performance that can be found in the Administrative Tools program group (Figure 12-13). Windows Server 2003 also includes a command-line tool called logman that can be used in conjunction with Performance Logs and Alerts to trace IIS and kernel events for advanced performance tuning. For general help regarding the syntax of using this tool, open a command-prompt and type logman /? to view the various options for running it.

click to expand
Figure 12-13: The Performance console

Tip

Other options for monitoring IIS include third-party SNMP monitoring applications and Microsoft Operations Manager (MOM). Monitoring servers is really a subject of its own; I cover only tools provided with Windows Server 2003 in this chapter.

Other Windows Server 2003 tools that can be useful in certain aspects of performance monitoring include:

Task Manager Can be used to display various system activity in real time. Task Manager can display names of applications that are currently running, memory and CPU usage of active processes, who is currently logged on to the server, and various memory and networking usage statistics.
Network Monitor Mainly used for troubleshooting problems with network connections and services, but can also be used to monitor network utilization statistics.
Web Application Stress Tool (WAST) You can download this tool from the Microsoft website; it simulates the effect of multiple web browsers simultaneously connecting to IIS to download content or run applications, and it can be configured to simulate various loads so you can see how your web server behaves under them and then tune it accordingly.

How to Monitor Performance

To use the Performance console to monitor the performance of an IIS machine, start by setting up a controlled environment or testbed network on which you can expose your server and its applications to predictable loads and measure its response. Using WAST is a good way to generate such loads, and Performance should be your main tool for collecting and analyzing the resulting data. To use Performance, you have to add the performance counters you want to measure; I’ll talk about which counters are useful to collect for tuning IIS machines in a moment.

Analyzing your server under predictable loads will likely expose bottlenecks, which are limitations in the hardware/software configuration that affect performance. Bottlenecks can result from hardware (insufficient memory or processing power, slow disk subsystem, or inadequate network connection) or software (applications, middleware, or back-end databases). Once you’ve identified possible bottlenecks, try to eliminate them by modifying hardware (adding more RAM, adding another processor, using a faster network adapter, or using RAID), tweaking software (recoding applications more efficiently, or using a faster database program), or tuning IIS performance using the procedures outlined previously in this chapter (changing properties sheet settings in IIS Manager, editing the Registry, and modifying metabase properties). Be aware that fixing a bottleneck in one area can sometimes create a bottleneck in another area or expose another bottleneck that was previously hidden by the first one.

The trick to performance tuning is to modify one setting or property at a time and then use Performance to observe the effect to see if performance improves or degrades. There’s no particular order to what you should try, just be systematic in how you do this, and don’t expect to ever get it perfect. Performance tuning is often a win/lose situation where improving things in one area can make them worse in another. In general, a good approach is to tweak hardware first, for example, adding more RAM is often the single most important action you can perform for boosting a server’s performance. If your server is using SSL, adding another processor can also significantly boost performance, as SSL encryption is a very processor-intensive activity. But don’t think hardware will solve all your problems, as one bad Registry or metabase setting (such as disabling caching) can have a tremendous negative impact on IIS performance.

Once your server has been thoroughly tuned in a controlled environment and your applications have been thoroughly debugged, move the server from the development stage to production and connect it to your real live network. Continue collecting performance data periodically, especially during heavy load times, to establish a baseline of your server’s normal operation. Once you’ve established your baseline, you can continue tuning your server and comparing the results to it.

Another reason for continuing to collect performance data over the long haul is to monitor usage pattern changes. For example, as your website becomes popular, usage will rise and your web server’s performance may start to suffer. At this point, you are using Performance as a tool for capacity planning to determine when you should upgrade your hardware or software to meet changing demands. Performance monitoring and capacity planning should continue on a regular basis throughout the life of your server so you can anticipate issues before they arise and adjust your configuration accordingly so that users always experience satisfactory response and throughput.

Important Performance Counters

There are hundreds of performance counters you can collect for Windows Server 2003 in general and IIS 6 specifically, so I can’t cover all of them here. Instead, I’ll summarize some of the more common and useful counters for monitoring performance of IIS machines, including general counters related to system resources and specific counters related to IIS services. For more information on available IIS counters, see the Performance Counters Reference in IIS Help.

General Counters

When monitoring any aspect of Windows Server 2003 (including IIS), you should always collect counters for the four system resources: memory, processor, disk, and network. Some of the more useful counters for these resources are shown in Table 12-1, along with comments relating to what values are acceptable for IIS and what values may indicate a bottleneck. Note that the disk counters may refer to either a logical or physical disk, depending on which object you select. Counters are expressed as object:counter, for example Memory:Available Bytes.

Table 12-1: General Performance Counters Useful for Monitoring IIS
Object	Counter	Comment
Memory	Available Bytes	Keep greater than 20MB.
	Cache Bytes	If this starts to decrease, IIS may be running out of memory.
	Committed Bytes	Keep less than 75 percent of physical memory.
	Pages/sec	Keep low (under 20); if it's high (over 80), you need more RAM.
	Page Faults/sec	Too many hard page faults can degrade performance. Compensate by adding more RAM.
	Pool Nonpaged Bytes	If slowly rising over time, your application may have a memory leak.
Processor	% Processor Time	If higher (over 80) for sustained period but disk and network utilization are low, there may be a processor bottleneck.
Disk	% Disk time	Keep as low as possible.
	Avg. Disk Bytes/Transfer	Should be as high as possible
	Avg. Disk Queue Length	Should be 4 or less.
Network	Bytes Total/sec	Compare to bandwidth of network card to see if network connection is the bottleneck.
System	Context Switches/sec	Should be low with respect to System: System Calls/sec counter.
	Processor Queue Length	If 2 or more for sustained period, there may be a processor bottleneck.
Paging File	% Usage	Make sure paging file is at least twice the size of physical memory. If this counter is high, consider using disk striping.

Tip

When logging performance data, put your log files on a separate drive because the logging process itself has a performance impact on the machine.

WWW Service Counters

Table 12-2 lists some counters to watch that specifically relate to the WWW Service.

Table 12-2: Useful Performance Counters for Monitoring the WWW Service
Object	Counter	Comment
WWW Service	Bytes Total/Sec	Should be as high as possible.
	File Cache %	Shows how often IIS is finding requested files in the cache; if low, consider redesigning application to improve cache hit rate.
	File Cache Hits	Should be as high as possible if you have static content, but may be low if Kernel: URI Cache Hits % counter is high.
	ISAPI Extension	If this drops under heavy load, your application may be a bottleneck and may need to be redesigned.

ASP Counters

Table 12-3 lists some counters to watch that specifically relate to ASP.

Table 12-3: Useful Performance Counters for Monitoring ASP
Object	Counter	Comment
Active Server Pages	Request Wait Time	Should be low, but response as perceived by users is often more a result of network latency.
	Requests Queued	Keep low. If greater than metabase property AspRequestQueueMax, additional connection attempts receive an “HTTP 500—Server Too Busy” error.
	Requests/Sec	If low under heavy server load, your application may be a bottleneck.

Challenge

You have an IIS 6 machine that you plan to use to host two web applications, one a large and complex ASP application that will be used as your company intranet site, which will have lots of static content, and the other an ISAPI application that will be used for online provisioning against a back-end database, which must have high availability. How would you configure IIS for maximum performance of these two applications? What isolation mode would you use? Would you assign them to the same or different application pools? What QoS features would you use to ensure high availability for your ISAPI application? What metabase properties might you modify to tune the performance of your ASP application? What other general steps might you take to tune the performance of your server? How would you plan to monitor your server's performance to ensure that it performs properly in a production environment?