Chapter 13: Performance Tuning and Monitoring

Monitoring and performance tuning are essential parts of Web administration. You monitor servers to ensure that they’re running smoothly and to troubleshoot problems as they occur. You tune the performance of servers to achieve optimal performance based on the current system resources and traffic load. Microsoft Windows Server 2003 includes several tools that you’ll use to monitor Internet Information Services (IIS). The key tools are the Performance tool, Windows event logs, and the IIS access logs. You’ll often use the results of your monitoring to optimize IIS.

Performance tuning is as much an art as it is a science. You often tune performance based on trial and error. You adjust the server, monitor the server’s performance over time, and then gauge the success of the updated settings. If things aren’t working as expected, you adjust the settings again. In an ideal world you’d have staging or development servers that are similar in configuration to your production servers to work with while tuning server performance. Then, once you’ve made adjustments that worked in staging, you could configure these changes on the production servers.

Monitoring IIS Performance and Activity

Monitoring IIS isn’t something you should do haphazardly. You need to have a clear plan—a set of goals that you hope to achieve. Let’s look at some reasons that you might want to monitor IIS and the tools you can use to do this.

Why Monitor IIS?

Troubleshooting performance problems is a key reason for monitoring. For example, users might be having problems connecting to the server, and you might want to monitor the server to troubleshoot these problems. Here, your goal would be to track down the problem using the available monitoring resources and then to solve it.

Another common reason for wanting to monitor IIS is to use the results to improve server performance. Improving server performance can reduce the need for costly additional servers or additional hardware components, such as CPUs and memory. This allows you to squeeze additional processing power out of the server and budget for when you really need to purchase new servers and components.

To achieve optimal performance, you need to identify performance bottlenecks, maximize throughput, and minimize the time it takes for World Wide Web (WWW) applications to process user requests. You achieve this by doing the following:

• Monitoring memory and CPU usage and taking appropriate steps to reduce the load on the server, as necessary. Other processes running on the server might be using memory and CPU resources needed by IIS. Resolve this issue by stopping nonessential services and moving support applications to a different server.

• Resolving hardware issues that might be causing problems. If slow disk drives are delaying file reads, work on improving disk input/output (I/O). If the network cards are running at full capacity, install additional network cards for performing activities, such as backups or load balancing.

• Optimizing Web pages and applications running on IIS. You should test Web pages and IIS applications to ensure that the source code performs as expected. Eliminate unnecessary procedures and optimize inefficient processes.

Unfortunately, there are often tradeoffs to be made when it comes to resource usage. For example, as the number of users accessing IIS grows, you might not be able to reduce the network traffic load, but you might be able to improve server performance by optimizing Web pages and IIS applications.

Getting Ready to Monitor

Before you start monitoring IIS, you should establish baseline performance metrics for your server. To do this, you measure server performance at various times and under different load conditions. You can then compare the baseline performance with subsequent performance to determine how IIS is performing. Performance metrics that are well above the baseline measurements might indicate areas where the server needs to be optimized or reconfigured.

After you establish the baseline metrics, you should formulate a monitoring plan. A comprehensive monitoring plan involves the following steps:

1. Determine which server resources should be monitored to help you accomplish your goal

2. Set filters to reduce the amount of information collected

3. Configure performance counters to watch the resource usage

4. Log the usage data so that it can be analyzed

5. Analyze the usage data and replay the data as necessary to find a solution

These procedures are examined later in this chapter in the section entitled “Monitoring IIS Performance.” Although you should develop a monitoring plan in most cases, there are times when you might not want to go through all these steps to monitor IIS. In this case, use the steps that make sense for your situation.

Monitoring Tools and Resources

The primary tools you’ll use to monitor IIS are:

• Performance tool Configure counters to watch resource usage over time. Use the usage information to gauge the performance of IIS and determine areas that can be optimized.

• Access logs Use information in the access logs to find problems with pages, applications, and IIS. Entries logged with a status code beginning with a 4 or 5 indicate a potential problem. Access logs can be written in several different formats, including IIS log file format, National Center for Supercomputing Applications (NCSA) common log file format, and World Wide Web Consortium (W3C) extended log file format.

• Event logs Use information in the event logs to troubleshoot system-wide problems, including IIS and Indexing Service problems. The primary logs you’ll want to work with are the System, Security, and Application event logs.

Many other monitoring tools are available in the Microsoft Windows Server 2003 Resource Kit. The resource kit tools you’ll want to use include:

• HTTP Monitoring Tool Monitors Hypertext Transfer Protocol (HTTP) activity on the server and records the tracking information to a file or to the Windows Event logs. The information tracked can alert you to changes in HTTP activity. You can import the output file generated by the tool directly into Microsoft SQL Server as well.

• Playback Playback is a tool suite that includes two components: Recorder.dll and Playback.exe. Recorder.dll records ongoing activity at a Web site so that it can be played back. Playback.exe plays back the recorded activity on a Web site so that you can simulate real-world traffic on development or testing servers.

• Web Application Stress Tool Simulates Web activity so that you can evaluate server performance. Parameters you can set include the number of users, the frequency of requests, and the type of request. The tool produces a detailed report that tells you the number of requests, number of errors, elapsed time for processing requests, and more.

• Web Capacity Analysis Tool (WCAT) Tests different server and network configurations using workload simulations and content developed specifically for WCAT. When you change your hardware and software configuration and repeat the testing, you can identify how the new configuration affects server response.