Chapter 10 - Performance Tuning and Monitoring

Article
12/09/2009

Monitoring and performance tuning are essential parts of Web administration. You monitor servers to ensure they are running smoothly and 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 2000 includes several tools that you'll use to monitor Internet Information Services (IIS). The key tools are Performance Monitor, 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 work 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 you may 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 may be having problems connecting to the server, and you may 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 central processing units (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 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 may 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 may 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.
Optimizing Web pages and applications running on IIS. You should test Web pages and IIS applications to ensure 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 may not be able to reduce the network traffic load, but you may be able to improve server performance by optimizing Web pages and IIS applications.

Getting Ready to Monitor

Before you start monitoring IIS, you may want to 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 may 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:

Determine which server resources should be monitored to help you accomplish your goal.
Set filters to reduce the amount of information collected.
Configure performance counters to watch the resource usage.
Log the usage data so that it can be analyzed.
Analyze the usage data and replay the data as necessary to find a solution.

These procedures are examined later in the chapter under "Monitoring IIS Performance." While you should develop a monitoring plan in most cases, there are times when you may 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 Monitor 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.
Event logs Use information in the event logs to troubleshoot system-wide problems, including IIS and Indexing Service problems.

Many other monitoring tools are available in the Microsoft Windows 2000 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: PLAYBACK.EXE and RECORDER.DLL. 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.

Detecting and Resolving IIS Errors

IIS records errors in two locations: the IIS access logs and the Windows event logs. In the access logs, you'll find information related to missing resources, failed authentication, and internal server errors. In the event logs, you'll find IIS errors, IIS application errors, and errors related to other applications running on the server.

Examining the Access Logs

Access logs are created when you enable logging for Web, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) sites. Every time someone requests a file from your Web site, an entry goes into the access log, making the access log a running history of resource requests. Because each entry has a status code, you can examine entries to determine the success or failure of a request. Failed requests have a status code beginning with a 4 or 5.

The most common error you'll see is a 404 error, which indicates that a resource was not found at the expected location. You can correct this problem by doing the following:

Placing the file in the expected location
Renaming the file if the current name is different than expected
Modifying the linking file to reflect the correct name and location of the file

If you want to find the access log for a particular site, follow these steps:

Start the Internet Information Services snap-in and then, in the left pane (Console Root), click the plus sign (+) next to the computer you want to work with. If the computer isn't shown, connect to it as discussed in Chapter 2, "Core IIS Administration," in the section called "Connecting To Other Servers."
Right-click the Web, FTP, or SMTP site you want to manage, and then select Properties.
On the Enable Logging panel, you'll find a Properties button. Click this button to display a dialog box similar to the one shown in Figure 10-1.

Figure 10-1: The Logging Properties dialog box tells you where logs are being written.
The Log File Directory field shows the top-level directory for this site's logs. The default top-level directory is \%WinDir%\System32\LogFiles.
The Log File Name field shows the subdirectory and log file naming format. For example, if the name shows \W3SVC1\EXYYMMDD.LOG, you'll find the site's logs in the W3SVC1 subdirectory. The current log is the file in this subdirectory with the most recent date and time stamp. All other logs are archive files that could be moved to a history directory.

Now that you know where the log files are located for the site, you can search for errors in the log file. Because logs are stored as ASCII text, one way to do this would be to open a log in Micosoft Notepad or another text editor and search for error codes, such as 404. Another way to search for errors would be to use the FIND command. At a command prompt, you could search for 404 errors in any log file within the current directory using the following command:

find "404" *

Once you identify missing files, you can use any of the previously recommended techniques to resolve the problem. You'll learn more about access logs and status codes in Chapter 11, "Tracking User Access and Logging."

Examining the Event Logs

Event logs provide historical information that can help you track down problems with services, processes, and applications. The events tracked are controlled by the event-logging service. When this service is started, user actions and system resource usage events can be tracked via the following event logs:

Application Log Records events logged by applications, such as IIS.
Directory Service Records events logged by Active Directory and its related services.
DNS Server Records Domain Name System (DNS) queries, responses, and other DNS activities.
File Replication Service Records file replication activities on the system.
Security Log Records events you've set for auditing with local or global group policies. Note that administrators must be granted access to the security log through user rights assignment.
System Log Records events logged by the operating system or its components, such as the failure of a service to start at bootup.

You access the event logs by completing the following steps:

Open the Start menu, select Programs, select Administrative Tools, and then select Event Viewer. This starts Event Viewer.
Event Viewer displays logs for the local computer by default. If you want to view logs on a remote computer, right-click the Event Viewer entry in the console tree (left pane), and then select Connect To Another Computer. In the Select Computer dialog box, enter the name of the computer you want to access, and then click OK.
Select the log you want to view, as shown in Figure 10-2. Use the information in the Source column to determine which service or process logged a particular event.

Figure 10-2: Event Viewer displays events for the selected log.

Entries in the main panel of Event Viewer provide a quick overview of when, where, and how an event occurred. To obtain detailed information on an event, double-click on its entry. The event type precedes the date and time of the event. Event types include:

Information An informational event, which is generally related to a successful action.
Success Audit An event related to the successful execution of an action.
Failure Audit An event related to the failed execution of an action.
Warning A warning. Details for warnings are often useful in preventing future system problems.
Error An error, such as the failure of a service to start.

Note: Warnings and errors are the two key types of events that you'll want to examine closely. Whenever these types of events occur and you are unsure of the cause, double-click on the entry to view the detailed event description.

In addition to type, date, and time, the summary and detailed event entries provide the following information:

Source The application, service, or component that logged the event
Category The category of the event, which is almost always set to None, but is sometimes used to further describe the related action
Event An identifier for the specific event
User The user account that was logged on when the event occurred, if applicable
Computer The name of the computer on which the event occurred
Description In the detailed entries, a text description of the event
Data In the detailed entries, any data or error code output by the event

The sources you'll want to look for include:

Active Server Pages (ASPs) Applications and ASP engines
CERTSVC Certificate services
Ci The Indexing Service
MSDTC Microsoft Distributed Transaction Coordinator
MSFTPSVC The FTP service
NNTPSVC The Network News Transfer Protocol (NNTP) service
SMTPSVC The SMTP service
W3SVC The World Wide Web service

If you want to see only warnings and errors, you can filter the log by completing the following steps:

From the View menu, select the Filter option. This opens the dialog box shown in Figure 10-3.
Clear the following check boxes: Information, Success Audit, and Failure Audit.
Select the Warning and Error check boxes.
Click OK. You should now see a list of warning and error messages only. Read these messages carefully and take steps to correct any problems that exist.

Figure 10-3: You can filter events so that only warnings and errors are displayed.

Monitoring IIS Performance

Performance Monitor is the tool of choice for monitoring IIS performance. Performance Monitor graphically displays statistics for the set of performance parameters you've selected for display. These performance parameters are referred to as counters. When you install IIS on a system, Performance Monitor is updated with a set of counters for tracking IIS performance. These counters can be updated when you install additional services and add-ons for IIS as well.

Performance Monitor creates a graph depicting the counters you're tracking. The update interval for this graph is configurable but, by default, is set to 1 second. As you'll see when you work with Performance Monitor, the tracking information is most valuable when you record performance information in a log file so that it can be played back. Also, Performance Monitor is helpful when you configure alerts to send messages when certain events occur, such as when an automatic IIS restart is triggered.

The sections that follow examine key techniques you'll use to work with Performance Monitor. You start Performance Monitor by selecting the Performance Monitor option from the Administrative Tools menu.

Choosing Counters to Monitor

The Performance Monitor only displays information for counters you're tracking. More than a hundred IIS counters are available, provided you've installed the related service. Counters are organized into object groupings. For example, all ASP-related counters are associated with the Active Server Pages object. You'll find counter objects for other services as well. A complete list of IIS-related counter objects follows:

Active Server Pages Counters for ASP scripts and applications running on the server
FTP Service Counters for the FTP service
HTTP Indexing Service Counters for the Indexing Service for Web sites, active queries, and caching results
Indexing Service Counters for Indexing Service that relate to indexing processes, word lists, and queries
Indexing Service Filter Counters provide additional performance information related to content filters and indexing speed related to filters
Internet Information Services Global Counters for all Internet services (WWW, FTP, SMTP, NNTP, and so on) running on the server
NNTP Commands Counters related to NNTP commands that users are executing on the server
NNTP Server Counters that track overall NNTP performance, such as the number of articles sent, received, and posted per second
SMTP NTFS Store Driver Counters for tracking the total number of messages and message streams
SMTP Server Counters that track overall SMTP performance, such as the number of messages sent and received per second
Web Service Counters for the World Wide Web Publishing Service

Counters for monitoring performance are summarized by issue and object in Table 10-1. The easiest way to learn about these counters is to read the explanations available in the Add Counters dialog box. Start Performance Monitor, click the Add button on the toolbar, and then select an object in the Performance Object field. Afterward, click the Explain button and then scroll through the list of counters for this object.

Table 10-1 Key Counters Used to Monitor Server Performance

Issue	Counter	Object Available For
ASP sessions	Session Duration	Active Server Pages
	Sessions Current	Active Server Pages
	Sessions Timed Out	Active Server Pages
	Sessions Total	Active Server Pages
ASP transactions	Transactions Aborted	Active Server Pages
	Transactions Committed	Active Server Pages
	Transactions Pending	Active Server Pages
	Transactions Total	Active Server Pages
	Transactions/Sec	Active Server Pages
Bandwidth usage	Current Blocked Async I/O Requests	Internet Information Services Global, Web Service, FTP Service
	Measured Async I/O Bandwidth usage	Internet Information Services Global, Web Service
	Total Allowed Async I/O Requests	Internet Information Services Global, Web Service
	Total Blocked Async I/O Requests	Internet Information Services Global, Web Service
	Total Rejected Async I/O Requests	Internet Information Services Global, Web Service
Caching and Memory	File Cache Flushes, URI Cache Flushes	Internet Information Services Global
	File Cache Flushes, URI Cache Flushes	Internet Information Services Global
	File Cache Hits, URI Cache Hits	Internet Information Services Global
	File Cache Hits %, URI Cache Hits %	Internet Information Services Global
	File Cache Misses, URI Cache Misses	Internet Information Services Global
	Maximum File Cache Memory Usage	Internet Information Services Global
	Script Engines Cached	Active Server Pages
	Template Cache Hit Rate	Active Server Pages
	Template Notifications	Active Server Pages
	Templates Cached	Active Server Pages
Connections	Connection Attempts/Sec	Web Service
	Current Anonymous Users	Web Service, FTP Service
	Current Connections	Web Service, FTP Service
	Current File Cache Memory Usage	Internet Information Services Global
	Maximum Connections	Web Service, FTP Service
	Current Files Cached	Internet Information Services Global
	Current NonAnonymous Users	Web Service, FTP Service
	Maximum Anonymous Users	Web Service, FTP Service
	Maximum NonAnonymous Users	Web Service, FTP Service
	Total Anonymous Users	Web Service, FTP Service
	Total Connection Attempts	Web Service, FTP Service
	Total Logon Attempts	Web Service, FTP Service
	Total NonAnonymous Users	Web Service, FTP Service
Errors	Errors During Script Runtime	Active Server Pages
	Errors From ASP Preprocessor	Active Server Pages
	Errors From Script Compiler	Active Server Pages
	Errors/Sec	Active Server Pages
	Not Found Errors/Sec	Web Service
	Requests Not Authorized	Active Server Pages
	Requests Not Found	Active Server Pages
	Requests Rejected	Active Server Pages
	Requests Timed Out	Active Server Pages
	Service Uptime	Web Service, FTP Service
	Total Not Found Errors	Web Service
Indexing	Active Queries	HTTP Indexing Service
	Queries Per Minute	HTTP Indexing Service
	Total Queries	HTTP Indexing Service
	Total Indexing Speed	Indexing Service Filter
Requests	Get Requests/Sec	Web Service
	Head Requests/Sec	Web Service
	ISAPI Extension Requests/Sec	Web Service
	Post Requests/Sec	Web Service
	Put Requests/Sec	Web Service
	Request Bytes In Total	Active Server Pages
	Request Bytes Out Total	Active Server Pages
	Requests Executing	Active Server Pages
	Requests Queued	Active Server Pages
	Requests Rejected	Active Server Pages
	Requests Succeeded	Active Server Pages
	Requests Timed Out	Active Server Pages
	Requests Total	Active Server Pages
	Requests/Sec	Active Server Pages
Throughput	Bytes Received/Sec	Web Service, FTP Service
	Bytes Sent/Sec	Web Service, FTP Service
	Bytes Total/Sec	Web Service, FTP Service
	Files Received/Sec	Web Service, FTP Service
	Files Sent/Sec	Web Service, FTP Service
	Files/Sec	Web Service, FTP Service
	Total Files Received	Web Service, FTP Service
	Total Files Sent	Web Service, FTP Service
	Total Files Transferred	Web Service, FTP Service

When Performance Monitor is monitoring a particular object, it can track all instances of all counters for that object. Instances are multiple occurrences of a particular counter. For example, when you track counters for the Web Service object, you often have a choice of tracking all Web site instances or specific Web site instances. Following this, if you configured CorpWeb, CorpProducts, and CorpServices sites, you could use Web Service counters to track a specific Web site instance or multiple Web site instances.

To select which counters you want to monitor, complete the following steps:

Start Performance Monitor by selecting the Performance Monitor option from the Administrative Tools menu.
Performance Monitor has several different views. Click View Chart on the toolbar to ensure you are in Chart view.

To add counters, click Add on the toolbar. This displays the Add Counters dialog box shown in Figure 10-4. The key fields are the following:
- Use Local Computer Counters Configure performance options for the local computer.
- Select Counters From Computer Enter the Uniform Naming Convention (UNC) name of the IIS you want to work with, such as \\ENGSVR01.
- Performance Object Select the type of object you want to work with, such as Active Server Pages.
- All Counters Select all counters for the current object.
- Select Counters From List Select one or more counters for the current object. For example, you could select Requests Not Found, Requests Queued, and Requests Total.
- All Instances Select all counter instances for monitoring.
- Select Instances From List Select one or more counter instances to monitor. For example, you could select instances of Anonymous Users/Sec for individual Web sites or for all Web sites.
  
  Figure 10-4: Select the counter you want to monitor.
  
  Tip Don't try to chart too many counters or counter instances at once. You'll make the display too difficult to read and you'll use system resources—namely, CPU time and memory—that may affect server responsiveness.
When you've selected all the necessary options, click Add to add the counters to the chart. Repeat this process as necessary to add other performance parameters.
Click Close when you're finished.

Creating and Managing Performance Monitor Logs

You can use performance logs to track the performance of IIS, and you can replay them later. As you set out to work with logs, keep in mind that the parameters you track in log files are recorded separately from the parameters you're charting in the Performance Monitor window. You can configure log files to update counter data automatically or manually. With automatic logging, a snapshot of key parameters is recorded at specific time intervals, such as every 15 seconds. With manual logging, you determine when snapshots are made. Two types of performance logs are available:

Counter logs These logs record performance data on the selected counters when a predetermined update interval has elapsed.
Trace logs These logs record performance data whenever their related events occur.

Creating and Managing Performance Logging

To create and manage performance logging, complete the following steps:

Access the Performance console by selecting the Performance option on the Administrative Tools menu.
Expand the Performance Logs And Alerts node by clicking the plus sign (+) next to it. If you want to configure a counter log, select Counter Logs. Otherwise, select Trace Logs.
As shown in Figure 10-5, you should see a list of current logs (if any) in the right pane. A green log symbol next to the log name indicates logging is active. A red log symbol indicates logging is stopped.

Figure 10-5: Current performance logs are listed with summary information.
You can create a new log by right-clicking in the right pane and selecting New Log Settings from the shortcut menu. A New Log Settings box appears asking you to give a name to the new log settings. Type a descriptive name here before continuing.
Click Add to add the counters you wish to log. Click OK to return to the Performance tool.

To manage an existing log, right-click its entry in the right pane and then select one of the following options:
- Start Activates logging
- Stop Halts logging
- Delete Deletes the log
- Properties Displays the Log Properties dialog box

Creating Counter Logs

Counter logs record performance data on the selected counters at a specific sample interval. For example, you could sample performance data for the Web service every 5 minutes. To create a counter log, complete the following steps:

Select Counter Logs in the left pane of the Performance console, and then right-click in the right pane to display the shortcut menu. Select New Log Settings.
In the New Log Settings dialog box, type a name for the log, such as HTTP Performance Monitor or Total Request Monitor, then click OK.
In the General tab, click Add to display the Select Counters dialog box. This dialog box is identical to the Add Counters dialog box shown previously in Figure 10-4.
Use the Select Counters dialog box to add counters for logging. Click Close when you're finished.
In the Sample Data Every field, type in a sample interval and select a time unit in seconds, minutes, hours, or days. The sample interval specifies when new data is collected. For example, if you select a sample interval of 15 minutes, the log is updated every 15 minutes.

As shown in Figure 10-6, click the Log Files tab and then specify how the log file should be created using the following fields:
- Location Sets the folder location for the log file.
- File Name Sets the name of the log file.
- End File Names With Sets an automatic suffix for each new file created when you run the counter log. Logs can have a numeric suffix or a suffix in a specific date format.
- Start Numbering At Sets the first serial number for a log that uses an automatic numeric suffix.
  
  Figure 10-6: Configure the log file format and usage.
- Log File Type Sets the type of log file to create. Use Text File – CSV for a log file with comma-separated entries. Use Text File – TSV for a log file with tab-separated entries. Use Binary File to create a binary file that can be read by Performance Monitor. Use Binary Circular File to create a binary file that overwrites old data with new data when the file reaches a specified size limit.
  
  Tip If you plan to use Performance Monitor to analyze or view the log, use one of the binary file formats.
- Comment Sets an optional description of the log, which is displayed in the Comment column.
- Maximum Limit Sets no predefined limit on the size of the log file.
- Limit Of Sets a specific limit in kilobytes on the size of the log file.
As shown in Figure 10-7, click the Schedule tab and then specify when logging should start and stop.
You can configure the logging to start manually or automatically at a specific date. Select the appropriate option and then specify a start date if necessary.

Figure 10-7: Specify when logging starts and stops.

Tip Log files can grow in size very quickly. If you plan to log data for an extended period, be sure to place the log file on a drive with lots of free space. Remember, the more frequently you update the log file, the higher the drive space and CPU resource usage on the system.

The log file can be configured to stop in the following ways:
- Manually
- After a specified period of time, such as 7 days
- At a specific date and time
- When the log file is full (if you've set a specific file size limit)
Click OK when you've finished setting the logging schedule. The log is then created and you can manage it as explained in the "Creating and Managing Performance Logging" section of this chapter.

Creating Trace Logs

Trace logs record performance data whenever events for their source providers occur. A source provider is an application or operating system service that has traceable events. On domain controllers, you'll find System, Local Security Authority, and Active Directory:NetLogon providers. On other servers, the System and Local Security Authority providers probably will be the only providers available.

To create a trace log, complete the following steps:

Select Trace Logs in the left pane of the Performance console, and then right-click in the right pane to display the shortcut menu. Select New Log Settings.
In the New Log Settings dialog box, type a name for the log, such as Disk I/O Trace or Network TCP/IP Trace, then click OK. This opens the dialog box shown in Figure 10-8.
If you want to trace operating system events, select the Events Logged By System Provider option button. As shown in Figure 10-8, you can now select system events to trace.

Caution: Collecting page faults and file detail events puts a heavy load on the server and causes the log file to grow rapidly. Because of this, you should collect page faults and file details only for a limited amount of time.
If you want to trace another provider, select the Nonsystem Providers option button and then click Add. This displays the Add Nonsystem Providers dialog box, which you'll use to select the provider to trace.
When you're finished selecting providers and events to trace, click the Log Files tab. You can now configure the trace file as detailed in Step 6 of the "Creating Counter Logs" section of this chapter. The only change is that the log file types are different. With trace logs, you have two log types:

Figure 10-8: Use the General tab to select the provider to use in the trace.
- Sequential Trace File Writes events to the trace log sequentially up to the maximum file size (if any)
- Circular Trace File Overwrites old data with new data when the file reaches a specified size limit
Select the Schedule tab and then specify when tracing starts and stops.
You can configure the logging to start manually or automatically at a specific date. Select the appropriate option and then specify a start date if necessary.
You can configure the log file to stop manually, after a specified period (such as 7 days), at a specific date and time, or when the log file is full (if you've set a specific file size limit).
When you finish setting the logging schedule, click OK. The log is then created and can be managed, as explained in the "Creating and Managing Performance Logging" section of this chapter.

Replaying Performance Logs

When you're troubleshooting problems, you'll often want to log performance data over an extended period and analyze the data later. To do this, complete the following steps:

Configure automatic logging as described in the "Creating Counter Logs" section of this chapter.
Load the log file in Performance Monitor when you're ready to analyze the data. To do this, click View Log File Data on the Performance Monitor toolbar. This displays the Select Log File dialog box.
Use the Look In selection list to access the log directory, and then select the log you want to view. Click Open.
Counters you've logged are available for charting. Click Add on the toolbar and then select the counters you want to display.

Configuring Alerts for Performance Counters

You can configure alerts to notify you when certain events occur or when certain performance thresholds are reached. You can send these alerts as network messages and as events that are logged in the application event log. You can also configure alerts to start applications and performance logs.

To add alerts in Performance Monitor, complete the following steps:

Select Alerts in the left pane of the Performance console, and then right-click in the right pane to display the shortcut menu. Select New Alert Settings.
In the New Alert Settings dialog box, type a name for the alert, such as ASP Error Alert or High User Connection Alert. Then click OK. This opens the dialog box shown in Figure 10-9.
In the General tab, type an optional description of the alert in the Comment field. Then click Add to display the Select Counters To Log dialog box. This dialog box is identical to the Add Counters dialog box shown previously in Figure 10-4.

Figure 10-9: Use the Alert dialog box to configure counters that trigger alerts.
Use the Select Counters To Log dialog box to add counters that trigger the alert. Click Close when you're finished.
In the Counters panel, select the first counter and then use the Trigger Alert When Value Is field to set the occasion when an alert for this counter is triggered. Alerts can be triggered when the counter is over or under a specific value. Select Over or Under and then set the trigger value. The unit of measurement is whatever makes sense for the currently selected counters. For example, to alert if processor time is over 95 percent, you would select Over, and then type 95. Repeat this process to configure other counters you've selected.
In the Sample Data Every field, type in a sample interval and select a time unit in seconds, minutes, hours, or days. The sample interval specifies when new data is collected. For example, if you set the sample interval to 5 minutes, the log is updated every 5 minutes.

Caution: Don't sample too frequently. You'll use system resources and may cause the server to seem unresponsive to user requests.

Select the Action tab, as shown in Figure 10-10. You can now specify any of the following actions to take place when an alert is triggered:
- Log An Entry In The Application Event Log Creates log entries for alerts
- Send A Network Message To Sends a network message to the computer specified
- Start Performance Data Log Sets a counter log to start when an alert occurs
- Run This Program Sets the complete file path of a program or script to run when the alert occurs
  
  Tip You can run any type of executable file, including batch scripts with the .bat or .cmd extension and Windows scripts with the .vb, .js, .pl, or .wsc extension. To pass arguments to a script or application, use the options of the Command Line Arguments panel. Normally, arguments are passed as individual strings. However, if you select Single Argument String, the arguments are passed in a comma-separated list within a single string. The Sample Arguments List at the bottom of the panel shows how the arguments would be passed.
Select the Schedule tab and then specify when alerting starts and stops. For example, you could configure the alerts to start on a Friday evening and stop on Monday morning. Then, each time an alert occurs during this period, the specified actions are executed.

Figure 10-10: Set actions that are executed when the alert occurs.
You can configure alerts to start manually or automatically at a specific date. Select the appropriate option and then specify a start date if necessary.
You can configure alerts to stop manually, after a specified period of time such as 7 days, or at a specific date and time.
When you've finished setting the alert schedule, click OK. The alert is then created and you can manage it in much the same way that you manage counter and trace logs.

Tuning Web Server Performance

Now that you know how to monitor your Web servers, let's look at how you can tune the operating system and hardware performance. The areas I'll examine are the following:

Memory usage and caching
Processor utilization
Disk I/O
Network bandwidth and connectivity

Monitoring and Tuning Memory Usage

Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. One of the key reasons memory can be such a problem is that the IIS file cache is configured to use up to half of the available system memory by default. This means that on a system with 512 MB random access memory (RAM), the IIS file cache could use as much as 256 MB of memory. (Of course, the amount of memory used for caching depends on the number of files and the frequency of requests.)

Caching and virtual memory settings can also present a problem. Adding memory when there is a caching or virtual memory problem on the server won't solve performance problems. Because of this, you should always check for memory, caching, and virtual memory problems at the same time.

To rule out memory, caching, and virtual memory problems with the server, you should do the following:

Configure application performance
Configure data throughput

Once you've performed these tasks and rebooted the server, you can monitor the server's memory usage to check for problems.

Setting Application Performance

Application performance determines the responsiveness of foreground and background applications that may be running on the system. In most cases, you want a server to be equally responsive to foreground and background applications rather than give precedence to an application the Web administrator may be running on the computer. To ensure the server is responsive to background applications, follow these steps:

Click Start, point to Settings, and then select Control Panel. Double-click System. This starts the System utility.
Access the Advanced tab in the System utility and then display the Performance Options dialog box by clicking Performance Options.
Select Background Services and then click OK.

Setting Data Throughput

If you use the server primarily as a Web server, you should configure the server as an application server. This setting optimizes the server for networking performance, makes more memory available to Web applications, and enhances the multiprocessor capabilities of the server. To configure the server as an application server, complete the following steps:

Click Start, point to Settings, and then click Network And Dial-Up Connections.
Right-click Local Area Connection and then select Properties. This displays the Properties dialog box shown in Figure 10-11.

Figure 10-11: Use the Local Area Connection Properties dialog box to configure file and printer sharing settings for the Web server.

Note: Servers with multiple network interface cards will have multiple network connections shown in Network And Dial-Up Connections. You should optimize each of these connections appropriately.
Select File And Printer Sharing For Microsoft Networks and then click Properties.
On the Server Optimization tab, select Maximize Data Throughput For Network Applications. Click OK.
You will need to reboot the server for these changes to take effect.

Checking Memory, Caching, and Virtual Memory Usage

Now that you've optimized the system, you can determine how the system is using memory and check for problems. Table 10-2 provides an overview of counters that you'll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks. The table is organized by issue category.

Table 10-2 Uncovering Memory-Related Bottlenecks

Issue	Counters to Track	Details
Physical and virtual memory usage	Memory\Available Kbytes Memory\ Committed Bytes	Memory\Available Kbytes is the amount of physical memory available to processes running on the server. Memory\Committed Bytes is the amount of committed virtual memory. If the server has very little available memory, you may need to add memory to the system. In general, you want the available memory to be no less than 5% of the total physical memory on the server. If the server has a high ratio of committed bytes to total physical memory on the system, you may need to add memory as well. In general, you want the committed bytes value to be no more than 75% of the total physical memory.
Memory caching	Memory\Cache Bytes Internet Information Services Global\ Current File Cache Memory Usage\ Internet Information Services Global\ File Cache Hits % Internet Information Services Global\ File Cache Flushes	Memory\Cache Bytes represents the total size of the file system cache. Internet Information Services Global\Current File Cache Memory Usage represents the current memory used by the IIS file cache. Internet Information Services Global\File Cache Hits % represents the ratio of cache hits to total cache requests, and reflects how well the settings for the IIS file cache are working. A site with mostly static files should have a very high cache hit percentage (70%–85%). Internet Information Services Global\File Cache Flushes tells you how quickly IIS is flushing files out of cache. If flushes are occurring too quickly, you may need to increase the time-to-live value for cached objects (ObjectCacheTTL). If flushes are occurring too slowly, you may be wasting memory and may need to decrease the time-to-live value for cached objects.
Memory page faults	Memory\Page Faults/sec Memory\ Pages Input/ sec Memory\ Page Reads/sec	A page fault occurs when a process requests a page in memory and the system cannot find it at the requested location. If the requested page is elsewhere in memory, the fault is called a soft page fault. If the requested page must be retrieved from disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults. Hard faults, however, can cause significant delays. Page Faults/sec is the overall rate at which the processor handles all types of page faults. Pages Input/sec is the total number of pages read from disk to resolve hard page faults. Page Reads/sec is the total disk reads needed to resolve hard page faults. Pages Input/sec will be greater than or equal to Page Reads/sec and can give you a good idea of your hard page fault rate. If there are a high number of hard page faults, you may need to increase the amount of memory or reduce the cache size on the server. Memory used by IIS is controlled by the MemCacheSize and MaxCachedFileSize settings.
Memory paging	Memory\Pool Paged Bytes, Memory\Pool Nonpaged Bytes	These counters track the number of bytes in the page and nonpaged pool. The paged pool is an area of system memory for objects that can be written to disk when they aren't used. The nonpaged pool is an area of system memory for objects that cannot be written to disk. If the size of the page pool is large relative to the total amount of physical memory on the system, you may need to add memory to the system. If the size of the nonpaged pool is large relative to the total amount of virtual memory allocated to the server, you may want to increase the virtual memory size.

Monitoring and Tuning Processor Usage

The CPU does the actual processing of information on your server. As you examine the performance of a server, you should focus on the CPUs after memory bottlenecks have been eliminated. If the server's processors are the performance bottleneck, adding memory, drives, or network connections won't overcome the problem. Instead, you may need to upgrade the processors to faster clock speeds or add additional processors to increase the upper capacity of the server. You could also move processor-intensive applications, such as SQL Server, to another server.

Before you make a decision to upgrade CPUs or add additional CPUs, you should rule out problems with memory and caching. If signs still point to a processor problem, you should monitor the performance counters discussed in Table 10-3. Be sure to monitor these counters for each CPU installed on the server.

Table 10-3 Uncovering Processor-Related Bottlenecks

Issue	Counters to Track	Details
Thread queuing	System\Processor Queue Length	This counter displays the number of threads waiting to be executed. These threads are queued in an area shared by all processors on the system. If this counter has a sustained value of 2 or more threads, you'll need to upgrade or add processors.
CPU usage	Processor\% Processor Time	This counter displays the percentage of time the selected CPU is executing a nonidle thread. You should track this counter separately for all processor instances on the server. If the % Processor Time values are high while the network interface and disk I/O throughput rates are relatively low, you'll need to upgrade or add processors.
ASP performance	Active Server Pages\Request Wait Time Active Server Pages\Requests Queued Active Server Pages\ Requests Rejected Active Server Pages\Requests/sec	These counters indicate the relative performance of IIS when working with ASPs. Active Server Pages\Request Wait Time is the number of milliseconds the most recent request was waiting in the queue. Active Server Pages\Requests Queued is the number of requests waiting to be processed. Active Server Pages\Requests Rejected is the total number of requests not executed because there weren't resources to process them. Active Server Pages\Requests/sec is the number of requests executed per second. In general, you don't want to see requests waiting in the queue and, if requests are queuing, the wait time should be very low. You also don't want to see requests rejected because resources aren't available. Keep these problems relative to the number of requests handled per second. You may notice some variance under peak loads. To resolve these issues you may need to upgrade or add processors.

Real World In many cases, a single server may not be sufficient to handle the network traffic load. In this case, you may need to scale your site across multiple servers. For example, you could replicate the site to additional servers and then distribute the traffic across these servers using a load balancer. If you already have a multiple-server Web farm, you could add additional Web servers.

Monitoring and Tuning Disk I/O

With today's high-speed disks, the disk throughput rate is rarely the cause of a bottleneck. That said, however, accessing memory is much faster than accessing disks. So, if the server has to do a lot of disk reads and writes, the overall performance of the server can be degraded. To reduce the amount of disk I/O, you want the server to manage memory very efficiently and page to disk only when necessary. You monitor and tune memory usage as discussed previously in the "Monitoring and Tuning Memory Usage" section of this chapter.

Beyond the memory tuning discussion, you can monitor some counters to gauge disk I/O activity. Specifically, you should monitor the counters discussed in Table 10-4.

Table 10-4 Uncovering Drive-Related Bottlenecks

Issue	Counters to Track	Details
Overall drive performance	PhysicalDisk\% Disk Time in conjunction with Processor\% Processor Time and Network Interface Connection\Bytes Total/sec	If the % Disk Time value is high and the processor and network connection values are not high, the system's hard drives may be creating a bottleneck. Be sure to monitor % Disk Time for all hard drives on the server.
Disk I/O	PhysicalDisk\Disk Writes/sec, PhysicalDisk\Disk Reads/sec, PhysicalDisk\Avg. Disk Write Queue Length, PhysicalDisk\Avg. Disk Read Queue Length Physical Disk\Current Disk Queue Length	The number of writes and reads per second tells you how much disk I/O activity there is. The write and read queue lengths tell you how many write or read requests are waiting to be processed. In general, you want there to be very few waiting requests. Keep in mind that the request delays are proportional to the length of the queues minus the number of drives in a RAID set.

Note: Counters for physical and logical disks may need to be enabled before they are available. To enable these objects, type the following commands at a command prompt:

Diskperf –y for a hard drive

Diskperf –yv for a software RAID set

Monitoring and Tuning Network Bandwidth and Connectivity

No other factor weighs more in a visitor's perceived performance of your server than the network that connects your server to the visitor's computer. The delay, or latency, between when a request is made and the time it is received can make all the difference. If there is a high degree of latency, it doesn't matter if you have the fastest server on the planet. The user experiences a delay and perceives that your servers are slow.

Generally speaking, the latency the user experiences is beyond your control. It is a function of the type of connection the user has and the route the request takes through the Internet to your server. The total capacity of your server to handle requests and the amount of bandwidth available to your servers are factors under your control, however. Network bandwidth availability is a function of your organization's connection to the Internet. Network capacity is a function of the network cards and interfaces configured on the servers.

A typical network card is equipped to handle a 100 Mbps Fast Ethernet connection with fair efficiency, which is much more traffic than the typical site experiences and much more traffic than the typical server can handle. Because of this, your organization's bandwidth availability is typically the limiting factor. If you have a shared T1 for all Internet activity, your servers are sharing the 1.4 Mbps connection with all other Internet traffic. If you have a dedicated T1 for your Web servers, your servers have 1.4 Mbps of bandwidth availability. If you have multiple T1s or a T3, the bandwidth available to your servers could range from 3 Mbps to 45 Mbps.

To put this in perspective, consider that the number of simultaneous connections your network can handle is relative to the speed of the connection, the average size of the data transferred per connection, and the permitted transfer time. For example, if you have a T1 and the typical data transfer per connection is 50 KB and transfer time allowable is 15 seconds, your connection could handle this capacity:

21 data transfers per second, or
294 simultaneous transfers

On the other hand, if you have a T1 and the typical data transfer per connection is 250 kilobytes and transfer time allowable is 15 seconds, your connection could handle this capacity:

15 data transfers per second, or
60 simultaneous transfers

The capacity of your network card can be a limiting factor in some instances. Most servers use 10/100 network cards, which can be configured in many different ways. Someone may have configured a card for 10 Mbps, or the card may be configured for half duplex instead of full duplex. If you suspect a capacity problem with a network card, you should always check the configuration.

Real World A T1 connection is a useful example for many commercial sites. Larger commercial sites are typically co-located at a hosting service, such as Genuity, and may have 100 Mbps or greater connections to the Internet. If this is the case for your site, keep in mind that some devices configured on your network may restrict the permitted bandwidth. For example, your company's firewall may be configured so that it only allows 5 Mbps for Web, 2 Mbps for FTP, and 1 Mbps for SMTP.

To determine the throughput and current activity on a server's network cards, you can check the following counters:

Network\Bytes Received/sec
Network\Bytes Sent/sec
Network\Bytes Total/sec
Network Current Bandwidth

If the total bytes-per-second value is more than 50% of the total capacity under average load conditions, your server may have problems under peak load conditions. You may want to ensure that operations that take a lot of network bandwidth, such as backups, are performed on a separate interface card. Keep in mind that you should compare these values in conjunction with PhysicalDisk\% Disk Time and Processor\% Processor Time. If the process time and disk time values are low but the network values are very high, there may be a capacity problem.

IIS provides several ways to restrict bandwidth usage and to improve bandwidth-related performance. These features are the following:

Bandwidth throttling
Connection limitations
HTTP compression

Configuring Bandwidth Throttling and Connection Limits

You can restrict bandwidth usage by enabling bandwidth throttling and limiting the maximum number of allowable connections. Bandwidth throttling restricts the total bandwidth available to a service or individual sites. Connection limitations restrict the total number of allowable connections to a service. Because users may be denied service when these values are exceeded, you should only enable these features when you are sure that this setting is acceptable.

Before you restrict bandwidth, you should monitor the network object counters discussed earlier in the chapter. If these counters indicate a possible problem, restricting bandwidth is one answer. You can configure bandwidth throttling for all Web and FTP sites on a server by completing the following steps:

In the Internet Information Services snap-in, right-click the icon for the computer that you want to work with, and then select Properties.
On the Internet Information Services tab, select the Enable Bandwidth Throttling check box.
In the Maximum Network Use box, type the maximum number of kilobytes per second (Kbps) you want IIS to use. Remember, this value is for all Web and FTP sites.
Click OK.

While you cannot configure bandwidth throttling for individual FTP sites, you can configure throttling for individual Web sites. To do so, complete these steps:

In the Internet Information Services snap-in, right-click the Web site you want to work with, and then select Properties.
On the Performance property sheet, select Enable Bandwidth Throttling.
In the Maximum Network Use box, type the maximum number of kilobytes per second you want the site to use.
Click OK.

Setting connection limits for Web and FTP sites was covered previously in this book. To learn how to configure limits for Web sites, see the "Restricting Incoming Connections and Setting Time-Out Values" section of Chapter 3, "Configuring Web Sites and Servers." For FTP sites, see the similarly named section in Chapter 7, "Managing FTP Servers."

Configuring HTTP Compression

With HTTP compression enabled, the Web server compresses files before sending them to client browsers. File compression reduces the amount of information transferred between the server and the client, which in turn can reduce network bandwidth usage, network capacity, and transfer time. For HTTP compression to work, the client browser must support HTTP 1.1, and this feature must be enabled. Although most current browsers support HTTP 1.1 and have the feature enabled by default, older browsers may not support HTTP 1.1. Older browsers will still be able to retrieve files from your site, but they won't be taking advantage of HTTP compression.

Before you enable compression, you should monitor the current processor usage on the server. HTTP compression adds to the overhead on the server, meaning it will increase overall processor utilization. If your site uses dynamic content extensively and process utilization (% Processor Time) is already high, you may not want to upgrade or add processors before enabling HTTP compression.

Once you've completed your processor evaluation and have decided to use HTTP compression, you can enable this feature by completing the following steps:

In the Internet Information Services snap-in, right-click the icon for the computer that you want to work with, and then select Properties.
Under Master Properties, select WWW Service, and then click Edit.
Select the Service tab, as shown in Figure 10-12.

Figure 10-12: Use the Service tab to configure HTTP compression.
To compress dynamic content, such as ASPs, select Compress Application Files. Compressed dynamic files are stored in memory.
To compress static files, such as HTML pages, select Compress Static Files. Compressed static files are stored on disk in the directory specified by the Temporary Folder field.
The Temporary Folder field is used to specify where compressed static files are stored until the time-to-live period expires. When using compression for static files, type the name and path of the directory you want to use. Or click Browse to locate a directory where compressed files will be stored.

Note: The directory must be on a local drive on a Windows NT file system partition. Additionally, the directory should not be shared and cannot be a compressed directory.
To limit the size of the static file cache, select Limited To, and then type a limit in megabytes for the directory.
Click OK twice.

Click to order