Friday, May 02, 2008

Optimizing IIS 6.0 Performance

Source: http://download.microsoft.com/download/7/4/f/74fe970d-4a7d-4034-9f5d-02572567e7f7/19_CHAPTER_6_Optimizing_IIS_6.0_Performance.doc

When you monitor your application servers to maintain a baseline of performance data, you can spot performance trends as they develop, take steps to prevent unsatisfactory performance, decide how to best tune or upgrade your servers, and determine whether your changes are beneficial. By tuning your Internet Information Services (IIS) version 6.0 application servers, you improve the client experience, help avoid bottlenecks, and can extend the interval between hardware upgrades.

In This Chapter

 Overview of Performance Monitoring and Tuning. 2

 Managing Network Activity. 11

 Controlling Memory Usage. 41

 Preventing Processor Bottlenecks. 51

 Improving Application Performance. 61

 Balancing Performance and Security. 71

 Optimizing Performance Through Design. 77

 Additional Resources. 88

Related Information

u        For information about using IIS logs to monitor and tune performance, see "Analyzing Log Filesiisrg_log_GADT" in this book.

u        For information about troubleshooting performance, see "Troubleshooting IIS 6.0iisrg_trb_COTA" in this book.

u        For information about IIS 6.0 capacity planning and scalability, see "Web Server Scalabilityiisrg_sca_OVERVIEW" in this book.

Performance monitoring is the process of capturing and analyzing performance data from different areas of your server environment, which include applications, memory, processors, hardware, and your network. You obtain performance data to help you recognize trends as they develop, prevent unsatisfactory performance, and optimize the use of your system resources. Monitoring also helps you decide when to upgrade your hardware and whether upgrades are actually improving your server's performance.

Although some performance problems and their solutions are immediate and obvious, others develop over time and require careful monitoring and tuning. First, monitor to establish a performance baseline against which to judge and compare the performance of your server; without a baseline, your tuning efforts might not give you optimal performance.

By monitoring performance and analyzing performance data, you can identify performance patterns to help you locate bottlenecks and to identify underused or overused resources. After locating a bottleneck, you can make changes to the component to improve performance. Bottlenecks can occur anywhere in your server environment at any time, so you must regularly monitor performance to capture baseline information about your system.

To get started with performance monitoring, familiarize yourself with the tools used, which include System Monitor, Performance Logs and Alerts, and Network Monitor; with the counters that are available for monitoring performance objects; and with the basics of setting up monitoring in order to collect useful data.

Using the appropriate tools, you can monitor your application server to collect data on performance, make specific changes in order to tune your server and its Web applications, evaluate the results of changes, and plan additional changes to help your application server run optimally. Which tools you should use, and when you should use them, depends on the data you need and your purpose in collecting it.

The Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; Windows® Server 2003, Datacenter Edition; or Windows® Server 2003, Web Edition operating system provides the Performance console, which includes System Monitor, Performance Logs and Alerts, and Task Manager. System Monitor and Performance Logs and Alerts are Microsoft Management Console (MMC) snap‑ins. In addition, you can access these tools through the Run dialog box by using the perfmon command.

From the Performance console, you can examine the output of performance counters, which monitor the activity of performance objects. Each performance counter is named based on the object from which it collects data (for example, a processor, process, or thread) and the type of data that it collects (for example, the Processor\% Processor Time performance counter reports the average percentage of processor time in use for the Processor performance object).

Windows Server 2003 provides several command-line tools that you can use to monitor performance. This section cites two command-line tools for performing event tracing. For more information about using command-line tools to monitor performance, see "Monitoring performance from the command line" in Help and Support Center for Windows Server 2003.

System Monitor enables you to collect and display real-time performance data for a local computer or remote computers according to criteria that you define. System Monitor can also display data that is collected in counter logs.

You can use System Monitor to monitor your server's activity and summarize its performance at selected intervals. You can display performance data in real-time charts or reports, collect data in files, and generate alerts when critical events occur. Use the data to determine the cause of system bottlenecks and to fine-tune system and application performance.

By default, the System Monitor graph is plotted on a scale of 0 through 100. For counters that register small values, you might need to change the scale. When interpreting the counters, remember that most of them show the most recently observed value, not a long-term average. Use Performance Logs and Alerts to log data over time and determine average values.

For more information about using System Monitor, see "Setting Up Monitoringiisrg_per_BZLW" later in this chapter and "System Monitor overview" in Help and Support Center for Windows Server 2003.

Use Performance Logs and Alerts to automatically collect performance data in logs and to send alerts based on criteria that you set:

u        Create custom log files that automatically log the values for specified counters based on the start and stop times that you provide.

u        Set an alert on a counter that defines what action you want the system to take (for example, send an alert, run a program, make an entry in a log file, or initiate logging) when the alert condition is met.

u        View counter data during or after collection. After collecting data in logs, use System Monitor to view the data, or export the data to a spreadsheet or database application.

A binary log file format is provided for circular logging or for logging instances, such as threads or processes, that begin after the system starts logging data. (Circular logging is the process of continuously logging data to a single file, overwriting previous data with new data.)

For more information about Performance Logs and Alerts, see "Performance Logs and Alerts overview" in Help and Support Center for Windows Server 2003.


Note

You can also monitor your server by examining IIS logs. For information about IIS logs, see "Analyzing Log Filesiisrg_log_GADT" in this book.


Use Task Manager to monitor key indicators of your computer's performance.

The Performance tab displays a dynamic overview of your computer's performance, including usage history for CPU and memory; the total number of handles, threads, and processes currently running on the computer; and physical memory, kernel memory, and commit memory usage.

The Processes tab shows information about the processes running on your computer. You can select columns to display. For example, display information about CPU and memory usage, page faults, handle count, and a number of other parameters.

For more information about Task Manager, see "Task Manager" in Help and Support Center for Windows Server 2003.

A Web request goes through many layers of the operating system, most of which can be tuned. By tracing IIS and kernel events, you can pinpoint Web bottlenecks on the server, and can often determine where to tune your server for improved performance. You can use the trace data with performance monitors, capacity planning tools, and applications that analyze information relating to system resource usage.

Use the Log Manager and Trace Report command-line tools in Windows Server 2003 to collect and report trace data relating to IIS and kernel events:

u        Use the Log Manager tool (Logman.exe) to collect trace data for specified IIS and kernel events.

u        Then use the Trace Report tool (Tracerpt.exe) to process the event trace log and to generate trace analysis reports and comma-delimited files for the events.

For information about Logman.exe and Tracerpt.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Command-line reference A-Z. For information about using Log Manager and Trace Report with IIS 6.0, including syntax examples and analysis of output reports, see "Capacity Planning Tracing" in IIS 6.0 Help, which is accessible from IIS Manager.

Network Monitor is a useful tool for conducting a network analysis of your Web applications. Use this tool to document the number of roundtrips that are required for a client to download a specific Web page from your server. Make adjustments to your applications, such as the changes recommended in "Optimizing Application Design and Administrationiisrg_per_JOLY" later in this chapter, and then rerun Network Monitor to verify that the adjustments improved performance.

Network Monitor collects data about the network traffic that flows to and from the network adapter of the computer on which it is installed. By capturing and analyzing that data, you not only can improve performance, you can prevent, diagnose, and solve many types of network problems.

You can configure Network Monitor to provide only the information that is most relevant to you. For example, you can configure capture triggers, which cause Network Monitor to start or stop capturing data when a circumstance or set of circumstances occurs, and you can configure capture filters to control the types of data that Network Monitor captures or displays.

Network Monitor monitors the frames in which data is sent over the network, which, in addition to the data, contain the addresses of the source and destination computers and the protocols in use.

Because using Network Monitor can affect server performance, you might want to run this tool when usage is low or for short periods during peak usage. Use capture filters so that you collect only the data that you need, then repeat each network capture one or more times to verify that the data you obtained accurately reflects network activity.

For more information about using Network Monitor, including how to design capture filters and set capture triggers, see the checklist "Monitoring network traffic on your local computer" in Help and Support Center for Windows Server 2003.

Both System Monitor and Performance Logs and Alerts allow you to examine the output of performance counters, which monitor the activity of specific performance objects. Each performance counter is named for the object for which it collects data and the type of data that it collects. For example, the Processor\% ProcessorTime counter is the primary indicator of processor activity, displaying the average percentage of busy time observed during the sample interval.

A performance object often offers a choice of more than one instance. Using the Processor object as an example, if you are monitoring a dual-processor computer, the first processor instance is 0 and the second processor instance is 1. A commonly used instance is the _Total instance, which monitors the sum of the values of a specific counter's instances.

Components of a counter path

The counter path contains the computer name, and the performance object, instance, and counter. It is typically represented in the following way:

\\ComputerName\Object(Instance)\Counter

 

 

The computer name is optional. If you do not designate a computer name, the counter monitors the local computer.

Again, using the Processor object as an example, if you want to monitor the percentage of processor time that your #0 processor uses, your selection is represented in the following way:

Processor(#0)\% ProcessorTime

 

 

Sampling methods for counters

Performance counters collect and display their data in one of two ways:

u        Instantaneous counters. These counters display the most recent measurement of an aspect of resource use. For example, the Process\Thread Count counter shows the number of threads for a particular process as of the last time it was measured. An instantaneous counter might have a name containing the word "Current." Unless the server has a steady workload, these counters might not provide meaningful data.

u        Averaging counters. Based on the previous two measurements, averaging counters derive an average value for the interval between the measurements. These counters typically calculate a percentage or the number of occurrences per second. For example, the Memory\Pages/sec counter shows the number of memory pages read over the sample interval, divided by the number of seconds in the interval. When you start one of these counters, no value is displayed until the second measurement is taken.

Windows Server 2003 provides hundreds of counters. Frequently used performance objects include cache, memory, process, and server. For more information about Windows performance objects and counters, see "Performance objects and counters" in Help and Support Center for Windows Server 2003.

When you install IIS, you automatically install the IIS performance counters, which include the following:

u        Web Service counters to monitor the World Wide Web Publishing Service (WWW service).

u        Web Service Cache counters to monitor the WWW service cache.

u        FTP Service counters to monitor the File Transfer Protocol (FTP) service.

u        Active Server Pages counters to monitor applications that run as Active Server Pages (ASP pages).

If you use Simple Network Management Protocol (SNMP) services to monitor your Web services, IIS makes available a set of counters by means of SNMP. They include SNMP FTP service counters and SNMP HTTP service counters, which you can use to monitor an SNMP WWW service. However, you cannot view the SNMP counters in System Monitor or Performance Logs and Alerts; you must use Windows Management Instrumentation (WMI) or a management information base (MIB) browser tool instead. For more information about specific IIS counters, including how to locate and view the SNMP counters, see "IIS 6.0 Performance Countersiisrg_cou_EWGJ" in this book.

Table 6.1 and Table 6.2 list some of the counters that are typically used for monitoring application servers. The tables include the preferred value of each counter and suggest values that might indicate performance problems.

Most of the values provided in this section are relative: Optimal values vary with the Web application, system, and network architecture. For example, data collected by the PhysicalDisk\Avg Disk Bytes/Transfer counter is different for different kinds of controllers and drives. Some counters may not be relevant to your applications. For example, data collected by the Active Server Pages\Transactions/sec counter is not relevant to a Web site with only static content.

In Table 6.1 and Table 6.2 (as in most of the tables in this chapter), ComputerName is omitted to conserve space. For example, the first counter in Table 6.1 is actually ComputerName\Memory\Pages/sec.

Table 6.1   Preferred Values for Frequently Used Performance Counters

Object\Counter

Preferred or Ideal Value

Memory\Pages/sec

0–20. (Unhealthy if greater than 80; probably indicates not enough RAM.)

Memory\Available Bytes

10% of physical memory.

Memory\Committed Bytes

No more than 75 percent of physical memory.

Memory\Pool Nonpaged Bytes

A steady value. (A slow rise might indicate a memory leak.)

Processor\% Processor Time

Less than 75 percent.

Processor\Interrupts/sec

Depends on the processor, and on network hardware and drivers. Up to 3,500 for a 90–megahertz (MHz) Pentium; more than 19,000 for a 500–MHz Pentium or more than 58,000 for a 1.5–gigahertz (GHz) Pentium. Lower is better. If the value is too high, try moving some hardware devices to a different server.

Processor\System Processor Queue Length

4 or less.

LogicalDisk\% Disk Time

PhysicalDisk\% Disk Time

As low as possible.

LogicalDisk\Avg. Disk Queue Length

PhysicalDisk\Avg. Disk Queue Length

Less than 4.

LogicalDisk\Avg. Disk Bytes/Transfer

PhysicalDisk\Avg. Disk Bytes/Transfer

As high as possible.

System\Context Switches/sec

Compare this value with the value of Web Service\Total Method Requests/sec. Context switches per request (Context Switches/sec divided by Total Method Requests/sec) should be low.

System\System Calls/sec

As low as possible.

Web Service\Bytes Total/sec

As high as possible.

Web Service\Total Method Requests/sec

As high as possible.

Web Service\Current Connections

As high as possible.

Web Service Cache\File Cache Hits %

As high as possible for static content.

Note: This value might be low if the Kernel URI cache hits percentage is high.

Web Service Cache\Kernel:URI Cache Flushes

As low as possible, relative to the number of requests.

Note: This number increases every time a file is flushed from the HTTP.sys response cache (HTTP.sys is the kernel-mode device driver in IIS 6.0), which means that the content has not been accessed in the past 2–4 minutes. The only way to decrease this number is to flush the cache less often, although frequent flushing can cause HTTP.sys to use more memory for content that is not being accessed.

Web Service Cache\Kernel:URI Cache Misses

As low as possible. (Each request for dynamic content increases the value of the counter by one.)

Web Service Cache\Kernel:URI Cache Hits %

As high as possible. (Applies to static unauthenticated content and dynamic content that is marked as cacheable.)

Active Server Pages\Request Wait Time

As low as possible.

Active Server Pages\Requests Queued

As low as possible.

Active Server Pages\Transactions/sec

As high as possible.

Note: ASP transactions degrade overall server performance because each transaction requires interaction with a database. If you are concerned about server performance, use ASP transactions sparingly.

 

The counters listed in Table 6.2 are useful for monitoring your FTP servers.

Table 6.2   Preferred Values for Useful FTP Performance Counters

Object\Counter

Preferred or Ideal Value

FTP Service\Bytes Sent/sec

As high as possible.

FTP Service\Bytes Received/sec

As high as possible.

FTP Service\Bytes Total/sec

As high as possible.

 

In addition to the counters in Table 6.1 and Table 6.2, the following system counters are useful for monitoring your server's use of system resources:

u        System\Threads

u        System\Processes

u        System\Context Switches/sec

For a discussion of system-related counters and how their data relates to the performance of your Web server, see "Identifying Processor Bottlenecksiisrg_per_VFVG" later in this chapter.

For more information about choosing which counters to monitor, including suggested counters for monitoring the main components of your server's operating system, see "Setting up a monitoring configuration" in Help and Support Center for Windows Server 2003.

Use the counters listed in Table 6.1 and Table 6.2 to generate a baseline log that typifies your server's performance under ordinary conditions. Be sure to obtain multiple logs so that your baseline data contains enough information to give you a good sense of your server's behavior. For example, you might log the recommended counters for one week of typical operation. Shorter logs, which you need to periodically create, can help you monitor how changes in network activity are affecting your system performance.

If you are new to Windows Server 2003 performance monitoring, open the Performance console and take a look at the data provided by a few counters.


To select performance objects and counters to view in System Monitor

1.         In Control Panel, double-click Administrative Tools, and then double-click Performance.

2.        On the System Monitor toolbar, click the Add button (+) to open the Add Counters dialog box.

3.        Click the Performance object list box to view a list of available performance objects, and then select an object to monitor.

When you select an object, the list box on the left shows the available counters for that object and the list box on the right displays the instances for that object.

4.        To select specific counters for the performance object, click Select counters from list (the default option), and then select the counters that you want to view.

After you select a counter, you can click Explain to view a description.

5.        If you want to monitor one or more specific instances of the counter (when available), select from the list of instances in the box on the right. Windows provides a default selection if you do not select a specific instance.

6.        Click Add to begin monitoring.

In its default view, System Monitor provides a list of active counters, including their object and instance, directly below the graphical display of counter data. Remember that many counters display the last observed value or a cumulative count, not an average value or rate.

To get started quickly, use the predefined System Overview log that Windows Server 2003 provides under Counter Logs. The System Overview log is configured to create a binary log in the systemroot\Perflogs folder that, after manual startup, is updated every 15 seconds until the log reaches a maximum size. To minimize the system resources used during logging, the System Overview log provides circular logging, which overwrites older data with new data.

By default, the log includes three counters: Memory\Pages/sec, PhysicalDisk(_Total)\Avg. Disk Queue Length, and Processor(_Total)\% Processor Time.

Interpreting the data from a binary log requires the use of a parser, such as the Log Parser tool (LogParser.exe), to extract the data and convert it to formatted text. You can obtain the Log Parser tool from the Internet Information Services (IIS) 6.0 Resource Kit companion CD.

For information about creating counter logs, including baseline IIS logs, see article 313064, "Monitor Web Server Performance by Using Counter Logs in System Monitor in IIS," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

For information about using Performance Logs and Alerts to create custom logs, see "Performance Logs and Alerts overview" in Help and Support Center for Windows Server 2003. For information about analyzing log data and a list of acceptable values for counters, see "Analyzing performance data" in Help and Support Center for Windows Server 2003.

When you set up performance monitoring, keep the following guidelines in mind:

u        Be selective when choosing which counters to run, because several counters running at the same time can cause a small decrease in performance and can consume disk space.

u        For routine monitoring, start by sampling data every 15 minutes.

u        If you are monitoring for a specific problem, try varying the length of the interval until you find the optimal setting for obtaining the data that you need.

For example, if you are monitoring the activity of a specific process at a specific time, set a frequent update interval; however, if you are monitoring a problem that reveals itself slowly, such as a memory leak, use a longer interval.

u        When deciding the logging interval, consider the overall length of time over which you want to monitor.

For example, you might sample data every 15 seconds for monitoring that is 4 hours or less. If you plan to monitor for 8 hours or more, set an interval longer than 300 seconds.

When you decide to change your system in any way, such as by tuning settings, adding hardware, or upgrading your system, follow these guidelines:

u        Always make changes one at a time. Unsatisfactory performance that appears to relate to a single component might be the result of bottlenecks involving multiple components. However, if you make multiple changes simultaneously, it is often impossible to assess the impact of each change. For this reason, even when you are troubleshooting performance problems that involve multiple components, you might need to address each problem individually, making changes one at a time.

u        Repeat monitoring after every change. Because tuning one resource can affect other resources, it is recommended that you monitor after every change that you make, being sure to monitor not only the area you changed but also more globally. Unless you monitor after you make a change, you cannot determine whether your change improved performance.

u        Review event logs. Sometimes poor or unsatisfactory performance generates output in event logs. Use Event Viewer to monitor events that appear in event logs, such as application, system, and security logs. In addition, IIS logs can provide you with information about your changes. For more information about Event Viewer, see "Event Viewer" in Help and Support Center for Windows Server 2003. For more information about IIS logs, see "Analyzing Log Filesiisrg_log_GADT" in this book.

u        Test your changes in a lab. When your changes are significant, test them in a performance lab before making the changes in a production environment.

u        Periodically, obtain a new performance baseline. After making several changes, monitor again to update your performance baseline. Compare the new baseline to previous logs to observe the actual effects your changes are having on performance and capacity.

Creating and maintaining a Web site involves using hardware, software, and network bandwidth to manage network traffic. Servers send out pages in response to requests. In order to issue a request, a browser first establishes a Transmission Control Protocol (TCP) connection with the server and then sends the request through the connection. Network traffic, as the term applies to Web servers, is the mixture of incoming requests and outgoing responses.

Network traffic typically occurs in bursts and clumps that are only partly predictable. For example, many intranet sites have activity peaks at the beginning and end of the day, and around lunchtime. However, the exact size of these peaks varies from day to day, and the actual traffic load changes from moment to moment. There is a direct relationship between the amount of traffic and the network bandwidth needed. Network bandwidth is the capacity of the transmission medium stated in bits per second (bps). On computer networks, greater bandwidth means faster data-transfer capability. The more visitors your site has and the larger the pages the site provides, the more network bandwidth your server requires.

Data traveling on a network is split into packets. In addition to the data that it carries, each packet includes about 20 bytes of header information and other network protocol information (this extra information is known as overhead). The amount of data in a packet is not fixed, and thus the ratio of overhead to data can vary. Most incoming HTTP requests are small. A typical request (for example, GET http://www.microsoft.com/default.asp), including the TCP/IP overhead, consists of no more than a few hundred bytes as it travels across the network.

Overhead can become an important consideration when you are estimating your site's bandwidth requirements and deciding how fast a connection you need. If current usage is close to the limits of your connection's capacity, an extra 20 percent for overhead might mean that you need the next faster type of connection.

Think of a server that displays static Hypertext Markup Language (HTML) text-only pages that average 5 kilobytes (KB), which is nearly equivalent to a full page of printed text. The server is connected to the Internet through a DS1/T1 line, which can transmit data at 1.536 megabits per second. Inherent overhead makes it impossible to use the full-rated T1 bandwidth of 1.544 megabits per second. For this 5‑KB file, protocol overhead is significant, amounting to about 30 percent of the file's size. For larger files, the overhead accounts for a smaller percentage of network traffic.

Table 6.3 shows the traffic generated by a typical request for a 5‑KB page. Note that all the figures for overhead are estimates. The precise number of bytes sent varies with each request.

Table 6.3   Network Traffic Generated by a Request for a 5-KB Page

Traffic Type

Bytes Sent

TCP connection

180 (approx.)

GET request

256 (approx.)

5‑KB file

5,120

Protocol overhead

1,364 (approx.)

Total

6,920

 

To calculate the number of bits for this 5‑KB page, multiply the total number of bytes sent by 8 bits per byte:

6,920 × 8 = 55,360

As stated previously, a T1 line can transmit 1.536 megabits per second. Dividing bits per second by bits per page (1,536,000/55,360) indicates a maximum transmission rate of just under 28 pages per second. (Because modems add a start bit and a stop bit to each byte, the transmission rate through a modem is slower than the raw numbers appear to indicate.) For this small text-only page, Table 6.4 shows the relative speed for connections to several types of network interfaces and an estimated page delivery rate for each connection type.

Table 6.4   Relative Network Interface Speeds to Request a 5‑KB Page

Connection Type

Connection Speed

5-KB Pages Sent per Second

Dedicated PPP/SLIP via modem

28.8 kilobits per second (Kbps)

About half of 1 page

Frame Relay or fast modem

56 Kbps

Almost 1 page

Integrated Services Digital Network (ISDN)

128 Kbps

Just over 2 pages

Typical DSL

640 Kbps

Almost 11 pages

DS1/T1

1.536 megabits per second (Mbps)

26 pages

10‑megabit Ethernet

8 Mbps (best case)

(Up to) 136 pages

DS3/T3

44.736 Mbps

760 pages

OC1

51.844 Mbps

880 pages

100‑megabit Ethernet

80 Mbps (best case)

(Up to) 1,360 pages

OC3

155.532 Mbps

2,650 pages

OC12

622.128 Mbps

10,580 pages

1‑gigabit/sec Ethernet

800 Mbps (best case)

(Up to) 13,600 pages

 

If you add a small graphic to the 5‑KB page, the results are considerably different. An image, in the form of a .jpg file that appears on-screen as a 1-inch by 2-inch rectangle (the actual physical size depends on monitor settings), takes up about as much disk space as the original text file. Adding one such image file to each page nearly doubles the average page size and also the number of requests that are needed. This increased size reduces the number of pages that the server can send to the Internet on a DS1/T1 line to a maximum of about 15 pages per second, regardless of how fast the computer itself runs.

If a page contains several images, if the images are relatively large, or if the page contains multimedia content, the page can take much longer to download. You can often find simple solutions for improving download time, such as consolidating, removing, sizing down, or compressing images or converting images to a more compact graphics format. You might also connect to the network by using a faster interface (this change can improve performance for the server, but not necessarily for the client, as is discussed later in this section).

A site that serves primarily static HTML pages, especially pages with a simple structure, is likely to run out of network bandwidth before it runs out of processing power. In contrast, a site that performs a lot of dynamic page generation, or that acts as a transaction or database server, uses more processor cycles and can create bottlenecks in its processor, memory, disk, or network.

For more information about how to create more efficient Web pages, see "Creating a More Efficient Web Siteiisrg_per_TLBK" later in this chapter.

Browser Download Time

Up to this point, the bandwidth discussion has focused on the number of pages that a server can send in a specified amount of time. The second part of this discussion focuses on how long it takes a browser to download a page.

Consider how much time a browser needs to download a page that, including overhead, amounts to 90 KB, which equals about 720 kilobits. If you ignore network latency, which is the amount of time required for a packet or signal to travel from one point on a network to another (latency typically adds a few seconds before any of the data arrives), and if everything is working perfectly, a 720‑kilobit page downloads over a 28.8‑Kbps connection in about 25 seconds. The download takes longer if any blocking or bottlenecks occur at the server, if the network is overloaded and slow, or if the user's connection is slower than 28.8 Kbps (due to poor line quality, for example).

If the client computer has a higher bandwidth connection on an intranet, the download time is usually much shorter. If your Web site is on the Internet, however, you cannot count on a majority of users having faster connections.

Server-Side Request Processing

It takes about 52 connections at 28.8 Kbps to saturate a DS1/T1 line. Not accounting for delays (which are fairly typical), if no more than 52 clients simultaneously request the page used in the preceding example, and if the server can keep up with the requests, the clients all receive the 90‑KB page in the 25 seconds calculated in the example.

If 100 clients simultaneously request that same page, however, the total number of bits to be transferred is 100 × 737,280 (720 kilobits). It takes between 47 and 48 seconds for that many bits to travel over a DS1/T1 line. When that many bits are involved, the network connection for the server, not the client, becomes the limiting factor.

A DS3/T3 line carries nearly 45 Mbps, about 30 times the capacity of a DS1/T1 line, and it takes more than 1,500 clients at 28.8 Kbps to saturate its bandwidth. Moreover, the increase in download time for each new client is much smaller on a DS3/T3 line. When there are 2,000 simultaneous 28.8‑Kbps connections, for example, it still takes less than 33 seconds for a client to download the page.

This example assumes that the server is capable of performing the relevant processing and handling of 2,000 simultaneous connections, which is not the same as handling 2,000 simultaneous users: users occasionally stop to read or think, and typically spend only a small percentage of their time downloading, except while receiving streaming multimedia content. Because of this difference between users and connections, IIS 6.0 can support more users than the figures appear to indicate. A Web server on a DS1/T1 line can typically handle several hundred users connecting at 28.8 Kbps, and with a DS3/T3 line the number typically climbs to 5,000 or more. Although these numbers are derived from actual servers, you can expect performance to vary with differing content types and user needs, and with the number and type of services that a particular computer is performing.

These network performance differences scale linearly, and the scaling continues at higher data-transfer rates. Two DS3/T3 lines, for example, can serve approximately twice as many clients as one line can, provided that processor power is sufficient to keep up with user demand and no bottlenecks prevent your servers from operating at maximum processing power. Connecting to the network by using a faster interface often resolves any performance problems for the server, but not necessarily for the client, as is shown later in this section.

Perceived Delay, Acceptable Delay, and Site Performance

The amount of time in which a user perceives that a Web page appears, known as perceived delay, is not identical to the actual time that is required to fully display the page. If the first thing that the user sees when opening a page is a set of buttons that allow further navigation, the user might never know or care that the rest of the page takes longer than a minute to download. If, on the other hand, the page takes longer than a minute to download, and the navigation buttons do not appear until after the rest of the page, users might not wait for the download.

The length of an acceptable delay depends partly on the kind of information that the page provides, but no more than 30 seconds is usually considered acceptable. If the information is important, users are more likely, but still reluctant, to wait.

As a best practice, set minimum performance goals that specify the acceptable performance for each of your sites. For example, the managers of certain Microsoft e‑commerce Internet sites test their site performance against the following minimum performance goals:

u        All pages must load within 10 seconds.

u        Average CPU usage for each server must be less than 70 percent.

u        Available memory must remain stable throughout the test period.

u        The site must maintain 10 customer checkouts per second.

The primary functions of IIS 6.0 are to establish connections for clients, to receive and interpret requests, and to deliver files — all as quickly as possible. The pace at which these vital functions are performed depends, in large part, on two factors: the effective bandwidth of the link between the server and the network, and the capacity of this link and the server to support network resources.

The speed of the network interfaces also affects the pace. Some servers have two or more network interfaces, which are frequently called front-end and back-end servers. Front-end servers are client-accessible Web servers that run application server software, such as IIS, to handle traffic coming from the Internet. Front-end servers can add a layer of protection for your back-end servers, which include database servers, file servers, domain controllers, and WINS servers. Different interfaces do not necessarily run at the same speed. This is the case, for example, if a Web server is connected to a database server by means of a private network.

If more bandwidth is needed, the network must be upgraded or — in the case of shared-resource networks such as Ethernet — the network must be broken into subnets.

Bandwidth and Capacity

The main purpose of most Web servers is to manage input/output (I/O): Requests come in, and pages go out. Handling I/O requires a certain amount of bandwidth and other server resources as well. In addition to IIS 6.0, network I/O involves TCP/IP, which is implemented by Windows Server 2003 TCP/IP.

Network capacity is measured, in part, by the number of connections that the server establishes and maintains. Bandwidth is measured in several ways:

u        By the rate at which bytes are transferred to and from the server.

u        By the rate at which the server sends data packages, which include frames, packets, segments, and datagrams.

u        By the rate at which the server sends and receives files.

Effective bandwidth varies widely and depends upon the transmission capacity of the link, the server configuration, and the server workload. The values for a single server also change as it operates in response to demand and to competition for shared network resources.

To ensure that your network has sufficient bandwidth and capacity for the network activity it must support, monitor the following performance indicators:

u        Data transmission rates at the different Open Systems Interconnection (OSI) layers, because the components that transmit data reside in different layers.

u        File transfer rates, because a Web page often requires multiple file transfers.

u        TCP connections, because a plateau in connections established, or increases in connection failures and connection resets, can indicate insufficient bandwidth.

The simplest measure of the effective bandwidth of a server is the rate at which the server sends and receives data. System Monitor displays counts of data transmissions that are collected by many components of the server computer.

The components that collect data reside in different layers of the OSI reference model:

u        Counters on the Web, FTP, and Simple Mail Transfer Protocol (SMTP) services performance objects measure data transmitted at the OSI application layer.

u        Counters on the TCP object measure data transmitted at the transport layer.

u        Counters on the IP object measure data at the network layer.

u        Counters on the Network Interface object measure data at the data-link layer.

As a result of their different positions in the OSI stack, the counters collect different data. For example, the counters at the application layer measure data in the form in which the application sends it, counting the bytes sent before the data is divided into packets and prefixed with protocol headers and control packets. Counters at the application layer do not include retransmitted data.

In addition, the counters display the data in units native to the component being measured. For example, the Web Service object displays data in bytes, and the TCP object displays data in segments.

For more information about TCP/IP and about the OSI reference model, see "Additional Resourcesiisrg_per_PNPM" at the end of this chapter.

Tables 6.5 through 6.8 list and describe some of the counters that can be used to measure transmission rates. These counters display the transmission rates observed during the last sample interval; they do not display a rolling or cumulative average of the rate.

Counters for Monitoring Data Transmission Rates at the Application Layer

Table 6.5 lists counters at the application layer. As with all the Web Service counters, these collect data that shows the rate at which the WWW service (a user-mode service) is sending and receiving bits. These counters do not measure the transmittal rates for HTTP.sys.

Table 6.5   Counters for Measuring Data Transmission Rates at the Application Layer

Object\Counter

Value

Web Service\Bytes Sent/sec

The rate at which the WWW service is sending data, in bytes per second.

Web Service\Bytes Received/sec

The rate at which the WWW service is receiving data, in bytes per second.

Web Service\Bytes Total/sec

The rate at which the WWW service is sending and receiving data, in bytes per second (the sum of Web Service\Bytes Sent/sec and Web Service\Bytes Received/sec).

FTP Service\Bytes Sent/sec

The rate at which the FTP service is sending data, in bytes per second.

FTP Service\Bytes Received/sec

The rate at which the FTP service is receiving data, in bytes per second.

FTP Service\Bytes Total/sec

The rate at which the FTP service is sending and receiving data, in bytes per second (the sum of FTP Service\Bytes Sent/sec and FTP Service\Bytes Received/sec).

SMTP Server\Bytes Sent/sec

The rate at which the SMTP server is sending data, in bytes per second.

SMTP Server\Bytes Received/sec

The rate at which the SMTP server is receiving data, in bytes per second.

SMTP Server\Bytes Total/sec

The rate at which the SMTP server is sending and receiving data, in bytes per second (the sum of SMTP Service\Bytes Sent/sec and SMTP Service\Bytes Received/sec).

 

Analyzing the data

The IIS 6.0 service counters listed in Table 6.5 display the number of bytes transmitted on behalf of each service that runs on the server. To calculate the total number of bytes sent or received by all IIS 6.0 services, calculate the sum of the values for each service. To determine the proportion of bytes transmitted by each service, compute the ratio of bytes for one service to the sum of bytes for all services or for the network.

Data collected by the IIS 6.0 service counters underestimates the total number of bytes that the IIS 6.0 services actually transmit to the network. Because these values are collected at the application layer, they measure data only. They do not measure protocol headers, control packets, or retransmitted bytes. In general, the bytes counted by the services represent 60 to 70 percent of the total number of bytes transmitted by the services on the network. If the sum of bytes for all services accounts for two-thirds or more of total network bandwidth, you can assume that your network is running at or near the total capacity of its communications link.

If you are using bandwidth throttling to limit the amount of bandwidth that the WWW service or an individual Web site uses, or you want to evaluate whether bandwidth throttling might be useful, monitor the Web Service\Bytes Total/sec and the Web Service\Bytes Sent/sec counters. These counters can indicate whether your Web server has sufficient bandwidth to handle its load. If it does not, consider using bandwidth throttling to redistribute network availability.

For information about using bandwidth throttling, see "Throttling Bandwidth to Manage Service Availabilityiisrg_per_FCTH" later in this chapter.

Counters for Monitoring Data Transmission Rates at the Transport and Network Layers

Table 6.6 lists the counters on the TCP object. These counters monitor TCP segments — the unit of data that TCP sends down the protocol stack to IP. Windows Server 2003 provides two TCP objects, TCPv4 and TCPv6. Choose the counter that monitors the version of TCP that your server uses.

Table 6.6   Counters for Measuring Data Transmission Rates at the Transport Layer

Object\Counter

Value

TCPv4\Segments Sent/sec

TCPv6\Segments Sent/sec

The rate at which TCP segments are sent by using the TCP protocol.

TCPv4\Segments Received/sec

TCPv6\Segments Received/sec

The rate at which TCP segments are received by using the TCP protocol.

TCPv4\Segments/sec

TCPv6\Segments/sec

The rate at which TCP segments are sent and received by using the TCP protocol (the sum of Segments Sent/sec and Segments Received/sec).

TCPv4\Segments Retransmitted/sec

TCPv6\Segments Retransmitted/sec

The rate at which segments are transmitted that contain one or more bytes that TCP recognizes as having been transmitted before. Segments Retransmitted/sec is a subset of Segments Sent/sec and Segments/sec. To determine the proportion of transmissions caused by failed transmission attempts, divide Segments Retransmitted/sec by Segments Sent/sec.

 

Table 6.7 describes lists some of the datagram counters for the IP object. These counters monitor IP datagrams, which are the units of data that IP sends down the protocol stack to the network interface, such as a network adapter. The sum of IP\Datagrams/sec and IP\Datagrams Forwarded/sec represents the rate at which the server handles all IP datagrams.

Table 6.7   Counters for Measuring Data Transmission Rates at the Network Layer

Object\Counter

Value

IPv4\Datagrams Sent/sec

IPv6\Datagrams Sent/sec

The rate at which IP datagrams are sent to the network interfaces. This counter does not include datagrams forwarded to another server.

IPv4\Datagrams Received/sec

IPv6\Datagrams Received/sec

The rate at which IP datagrams are received from the network interfaces. This counter does not include datagrams forwarded to another server.

IPv4\Datagrams/sec

IPv6\Datagrams/sec

The overall transmission rate for IP datagrams being sent and received over the network interfaces (the sum of IP\Datagrams Sent/sec and IP\Datagrams Received/sec).

IPv4\Datagrams Forwarded/sec

IPv6\Datagrams Forwarded/sec

The rate, in incidents per second, at which the server attempts to find routes over which to forward IP datagrams to their final destination.

 

Analyzing the data

Counters on the TCP and IP performance objects display the rate at which data is sent and received over a TCP/IP connection at the transport and network layers, but the rate is not expressed in bytes. Counters on the IP performance object display data in datagrams, and counters on the TCP performance object display data in segments. It is difficult to convert segments to bytes because bytes per segment can vary from 8 KB to 64 KB (the size can increase to 1 gigabyte [GB] if a window scaling option is in effect), depending upon the size of the TCP/IP receive window and the maximum segment size negotiated when each connection is established.

Counters for Monitoring Data Transmission Rates at the Data-Link Layer

Table 6.8 lists several counters on the Network Interface performance object that might be useful for obtaining data about the network adapters on the server. The first instance of the Network Interface object that you see in System Monitor represents the loopback — a local path through the protocol driver and the network adapter; all other instances represent installed network adapters.

Table 6.8   Counters for Measuring Data Transmission Rates at the Data-Link Layer

Object\Counter

Value

Network Interface (Adapter ID)\Bytes Sent/sec

The rate, in seconds, at which bytes are sent over this network adapter. The counted bytes include framing characters. This counter is a subset of Network Interface\Bytes Total/sec.

Network Interface (Adapter ID)\Bytes Received/sec

The rate, in seconds, at which bytes are received over this network adapter. The counted bytes include framing characters. This counter is a subset of Network Interface\Bytes Total/sec.

Network Interface (Adapter ID)\Bytes Total/sec

The rate, in bytes per second, at which bytes are sent and received over this network adapter (the sum of Network Interface\Bytes Sent/sec and Network Interface\Bytes Received/sec).

Network Interface\Packets Sent/sec

The rate, in seconds, at which packets are sent over the network adapter.

Network Interface\Packets Received/sec

The rate, in seconds, at which packets are received over the network adapter.

 

Analyzing the data

Counters for the Network Interface performance object display the rate at which bytes are transmitted over a TCP/IP connection by monitoring the counters on the network adapter at the data-link layer. The values of these Network Interface counters include all prepended frame header bytes and bytes that have been retransmitted. They provide a relatively accurate estimate of the number of bytes transmitted over the network, but do not measure the bytes transmitted by a specific IIS 6.0 service.

It is useful to compare the data produced by these counters with other performance measures, such as the total number of connections served at a given bandwidth or processor use at different throughput rates.

Most static Web pages include multiple files, such as a file of text and one or more graphics files. File counters are available for each IIS 6.0 service. The counters for the WWW and FTP services count the total number of files that the services send and receive. The counters for the SMTP service tally total messages sent and total messages received, but not total messages sent and received.

Table 6.9 lists the counters for monitoring file and message transfers.

Table 6.9   Counters for Monitoring IIS 6.0 File and Message Transfers

Object\Counter

Value

Web Service\Total Files Sent

FTP Service\Total Files Sent

SMTP Server\Messages Sent Total

For the WWW and FTP services, the total number of files sent by the service since service startup.

For the SMTP service, the total number of outbound messages sent since service startup.

Web Service\Files Received

FTP Service\Total Files Received

SMTP Server\Messages Received Total

For the WWW and FTP services, the total number of files received by the service since service startup.

For the SMTP service, the total number of inbound messages received since service startup.

Web Service\Total Files Transferred

FTP Service\Total Files Transferred

For the WWW and FTP services, the sum of Total Files Sent and Total Files Received by the service since service startup.

The SMTP service does not provide a sum total counter.

 

The file counters for a particular service are an indicator of the network activity generated by that service. This data can also be associated with other performance measures to determine the effects of high and low file activity on server components.

The file counters in Table 6.9 display a cumulative total for all traffic since the service was started, regardless of when System Monitor was started. These counters do not display the current value or the rate at which files are transmitted. In IIS 6.0, the Web Service object (but not the FTP Service object) provides counters to measure the rate, in seconds, at which files are sent and received. The SMTP service provides similar counters that measure the rate at which messages are received and sent.

To calculate file transmission rates for the FTP service, you can use Performance Logs and Alerts to log the values for the file counters and the times at which measurements are taken. To derive the transmission rates, you can export the log files to a spreadsheet that associates the time of the measurement with the file count.

If the bandwidth of your server is insufficient to handle its workload, clients usually become aware of this before the server does. Client requests to the server might be rejected or time out, or the response might be delayed. On the server side, the indicators are less clear because the server continues to establish connections, receive requests, and transmit data.

Bandwidth shortages are not uncommon. You can detect one on your server (perhaps even before clients do) by monitoring the success and failure of connections established and rejected by TCP. With ample bandwidth, the server can establish and serve connections before they time out. If bandwidth is insufficient, the connections fail.

Table 6.10 lists the counters that monitor the success and failure of connections to TCP. Windows Server 2003 provides two TCP objects, TCPv4 and TCPv6; choose the counter that monitors the version of TCP that your server is using.

Table 6.10   Counters for Monitoring the Success or Failure of TCP Connections

Object\Counter

Value

TCPv4\Connections Established

TCPv6\Connections Established

The number of simultaneous connections supported by TCP. This counter displays the number of connections last observed to be in the ESTABLISHED or CLOSE-WAIT state. This counter displays the last observed value (indicating the current state); its value is not an average.

TCPv4\Connection Failures

TCPv6\Connection Failures

The number of connections that have failed since the service was started (regardless of when you started System Monitor). TCP counts a connection as having failed when it goes directly from sending (SYN-SENT) or receiving (SYN-RCVD) to CLOSED, or from receiving (SYN-RCVD) to listening (LISTEN).

TCPv4\Connections Reset

TCPv6\Connections Reset

The number of connections reset since the service was started (regardless of when you started System Monitor).

TCP counts a connection as having been reset when it goes directly from ESTABLISHED or CLOSE-WAIT to CLOSED.

 

The counters on the TCPv4 and TCPv6 objects are the best indicators of the success of connection requests. The counters on the Web Service and FTP Service performance objects monitor connections maintained by each IIS 6.0 service, but display only successful connection requests, not failed attempts. Like all counters at the application layer, they do not have information about connections until the connections are established.

For a discussion of performance counters that display the number of simultaneous connections maintained by IIS 6.0, see "Preventing Processor Bottlenecksiisrg_per_CQGH" later in this chapter.

Analyzing the Data

If your server does not support current or increasing demand, look for the following patterns when you analyze the data from the TCP\Connections counters:

u        Look for a plateau in the Connections Established counter value. If the counter value of TCP\Connections Established often reaches, but rarely exceeds, a maximum value (that is, the line in the graph rises and then reaches a plateau), the peak value is likely to indicate the maximum number of connections that can be established with the current bandwidth and application workload. If you observe such a pattern, the server probably cannot support any greater demand.

u        Look for consistent increases of the Connection Failures and Connections Reset counter values. An increasing number of failures and resets, or a consistently increasing rate of failures and resets, can indicate a bandwidth shortage. The counters that monitor failures and resets show cumulative values, but you can use Performance Logs and Alerts to set alerts on the values or to log values over time. You can then use a spreadsheet to calculate the rates at which connections are rejected and reset.


Note

Be cautious when interpreting the number of reset connections shown by the TCP\Connections Reset counter. Resets do not always indicate dropped or failed connections. To minimize connection overhead, many browsers routinely close connections by sending a TCP reset (RST) packet rather than by using a normal close operation. The TCP\Connections Reset counter does not distinguish between connections that are reset because they are dropped and those that are reset in order to be closed abruptly.


IIS 6.0 provides a set of Quality of Service (QoS) features to help you maintain acceptable service levels of data transmission on your network. The goal of QoS is to ensure that particular sites or applications do not monopolize server resources, such as memory or CPU cycles, which can adversely affect performance. QoS helps administrators control how IIS components — such as sites, application pools, or the WWW service as a whole — use resources.

If the bandwidth on your server is not sufficient to support demand, you can increase overall server bandwidth. You can also increase the effective bandwidth of existing communication links. Some suggestions on how to do so follow; many involve setting parameters that can only be modified by editing the Windows registry or the IIS 6.0 metabase.

It is frequently possible to reduce your use of bandwidth by optimizing Web application scripts or content. This option is worth looking into as an interim solution, partly because it can also improve response time and the user experience; however, if your client base is growing, you might eventually have to increase the bandwidth of your network connection anyway.

You can sometimes effectively increase existing bandwidth by limiting connections, by increasing the length of the connection queues, or by enabling HTTP Keep-Alives.

QoS in IIS provides the following methods for managing and maintaining network performance:

u        Limit connections in order to manage resources. Set limits on the number of connections allowed to a Web or FTP server or to specific sites. Use this feature to ensure that all your services remain active during periods of peak use and to protect against malicious attack.

u        Enable HTTP Keep-Alives in order to keep browser connections open. To maintain an open connection when browsers send multiple requests to download a Web page, be sure that HTTP Keep-Alives are enabled.

u        Set connection timeouts to save resources. To reduce the loss of processing resources consumed by idle connections, set connection timeouts on your Web server.

u        Use HTTP compression for faster downloads. To provide faster transmission time between IIS and compression-enabled browsers, use HTTP compression.

u        Throttle bandwidth to manage service availability. Limit the bandwidth used by your Web server so that the server remains available for other services, such as e‑mail or news, even during periods of peak use.

u        Use other IIS features to enhance performance. In addition to the QoS features, use other IIS features, including Web gardens, idle timeout, CPU monitoring, and processor affinity, to help you manage system resources and enhance performance:

For more information about IIS QoS features, see "Quality of Service" in IIS 6.0 Help.

Connection limits restrict the number of simultaneous connections to your Web sites and your Web server. If the number of connections reaches the maximum allotted, all subsequent connection attempts return an error and then are disconnected.

By limiting connections, you can conserve bandwidth for other uses, such as e‑mail servers, news servers, or another Web site running on the same installation. Limiting connections also conserves memory and protects against malicious attacks designed to overload your Web server with thousands of client requests.

To determine whether you need to limit connections, use System Monitor to log the Current Connections, Maximum Connections, and Total Connection Attempts counters on the Web Service and FTP Service objects. Continue logging until you have a good sense of the normal range; typically, logging can take several days to a week or more and must be repeated at regular intervals. For more information about performance logging, see "Enabling Logging" in IIS 6.0 Help and "Analyzing Log Filesiisrg_log_GADT" in this book.

You can establish global WWW service or FTP service connection limits for all Web and FTP sites, or you can establish connection limits on individual Web or FTP sites. IIS checks for a global connection limit before checking for connection limits on individual sites. If the global connection limit is exceeded, IIS returns error message 403.9 (Forbidden - Too Many Users) regardless of the connection limit set for individual sites. (You can customize the connection limit error message in IIS 5.0; however, IIS 6.0 does not offer that option.)

The following procedure tells how to set an overall connection limit for the WWW service. To set connection limits on the FTP service, follow the same procedure, but enter the connection limits on the FTP tab rather than the Performance tab.


Important

You must be a member of the Administrators group on the local computer to perform the following procedure or procedures, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run IIS Manager as an administrator. At a command prompt, type runas /User:Administrative_AccountName "mmc %systemroot%\system32\inetsrv\iis.msc".


 


To set a global connection limit for the WWW service

1.         In IIS Manager, expand the local computer, right-click the Web Sites folder, and then click Properties.

2.        On the Performance tab, select the Connections limited to check box, and in the box next to it, type the maximum number of simultaneous connections to allow for the WWW service.

3.        Click Apply, and then click OK.

 


Caution

If you set the Unlimited connections option on the Performance tab, IIS permits as many simultaneous connections as your memory, network bandwidth, and processor memory can support. Allowing an unlimited number of simultaneous connections to your Web server exposes all the sites on the server to the threat of a malicious attack, such as when thousands of clients are instructed to connect to the server, which delays subsequent service by consuming memory and bandwidth resources.


For more information about setting global and individual site connection limits, see "Limiting Connections" in IIS 6.0 Help.

Another way to limit connections to your Web server is through bandwidth throttling. For information about using this feature, see "Throttling Bandwidth to Manage Service Availabilityiisrg_per_FCTH" later in this chapter. For a list of counters related to performance, see "IIS 6.0 Performance Countersiisrg_cou_EWGJ" in this book. For information about connection timeouts, see "Setting Connection Timeouts to Save Resourcesiisrg_per_EPVZ" later in this chapter.

A browser typically makes multiple requests in order to download an entire Web page. To enhance server performance, most Web browsers request that the server keep the connection open across these multiple requests, which is a feature known as HTTP Keep-Alives.

Without HTTP Keep-Alives, a browser that makes numerous requests for a page containing multiple elements, such as graphics, might require a separate connection for each element. These additional requests and connections require extra server activity and resources, decreasing server efficiency. The additional connections also make a browser much slower and less responsive, especially across a slow connection.

HTTP Keep-Alives are enabled by default in IIS 6.0, which complies with the HTTP/1.1 specification for HTTP Keep-Alives. IIS holds open an inactive connection for as long as the ConnectionTimeout metabase property specifies (the default value is 120 seconds).

If you disable HTTP Keep-Alives, the server ignores a client's request to keep the connection open. Therefore, disable HTTP Keep-Alives only for a specific reason and if you clearly understand how this change affects your server.

HTTP Keep-Alives are required for integrated security or connection-based authentication services, such as Integrated Windows authentication. If you disable HTTP Keep-Alives for Web sites that use Integrated Windows authentication, requests to the Web site fail.

To verify that your server is running with HTTP Keep-Alives enabled, or to enable HTTP Keep-Alives if this feature is disabled, use the following procedure.


To enable HTTP Keep-Alives

1.         In IIS Manager, expand the local computer, expand the Web Sites folder, right-click the Web site for which you want to enable HTTP Keep-Alives, and then click Properties.

2.        On the Web Site tab, under Connections, select the Enable HTTP Keep-Alives check box.

3.        Click Apply, and then click OK.

Alternatively, you can enable HTTP Keep-Alives by setting the AllowKeepAlive metabase property to true (the default value).

Connection timeouts help reduce the amount of memory resources that are consumed by idle connections. Time-out settings also allow you to specify how long server resources are allocated to specific tasks or clients. When you enable connection timeouts, IIS 6.0 enforces the following types of connection timeouts at the connection level:

u        A connection timeout, in which the client has sent data to the server, but the client is now idle. Use the ConnectionTimeout metabase property to set a connection timeout limit for the WWW, FTP, Network News Transfer Protocol (NNTP), and SMTP services.

u        A request timeout, which prevents clients from issuing unreasonably slow requests to the server (for example, 1 bit per second). Use the HeaderWaitTimeout metabase property to set a request timeout for the WWW service.

u        A response timeout, which prevents malicious or malfunctioning clients from consuming resources by holding a connection open with minimal data. Use the MinFileBytesPerSec metabase property to set a response timeout for the WWW service.

Monitoring with Counters to Evaluate Connection Limits

In IIS 6.0, the default connection timeout settings are more restrictive than in earlier versions of IIS, which helps prevent denial of service attacks on the server. To determine whether you can improve performance by changing a default connection timeout setting or by adding an optional setting, begin by obtaining a baseline of how your server performs with the current connection limits. For example, use System Monitor to log the Current Connections, Maximum Connections, and Total Connection Attempts counters on the Web Service and FTP Service objects. Continue logging until you have a good sense of the normal range; typically, logging can take several days to a week or more and must be repeated at regular intervals.

After obtaining baseline performance data for the default configuration, make incremental changes to the connection timeout settings, and then collect additional performance data by using these same counters. Compare the results to determine if changing the connection limits improves performance, keeping in mind that more aggressive limits can increase protection against malicious attacks.

Setting Connection Timeouts by Using IIS Manager

Use the following procedure to set a global connection timeout for the WWW or FTP service.


To set a global connection timeout for the WWW or FTP service

1.         In IIS Manager, expand the local computer, right-click the Web Sites or FTP Sites folder, and then click Properties.

2.        On the Web Site or FTP Site tab, in the Connection timeout box, type the maximum number of seconds that IIS will maintain an idle connection before resetting the connection. (The default value for both Web and FTP sites is 120 seconds.)

For the WWW service, verify that the Enable HTTP Keep-Alives check box is selected.

3.        Click Apply, and then click OK.

You can also set global connection timeouts on SMTP and NNTP servers. In addition, you can set connection timeouts for an individual Web or FTP site. For more information about setting these connection timeouts, see "Setting Connection Timeouts" in IIS 6.0 Help.

Setting Connection Timeouts by Editing the Metabase

IIS 6.0 provides three metabase properties, ConnectionTimeout, HeaderWaitTimeout, and MinFileBytesPerSec, which you can use to set different types of connection timeouts. In IIS 6.0, these properties replace the ServerListenTimeout metabase property, which is no longer used for the WWW service but can be used for the FTP, SMTP, and NNTP services.

Setting connection timeouts

The ConnectionTimeout metabase property specifies the amount of time (in seconds) that the server waits before disconnecting an inactive connection. IIS applies this timeout limit after the client sends the first request to the server and the client is idle. The default value is 120 seconds for the WWW and FTP services (global settings); 120 seconds for individual Web and FTP sites; and 10 minutes for the SMTP and NNTP services. (In IIS Manager, when you change the value of the ConnectionTimeout property, you change this setting.)

For security reasons, the ConnectionTimeout property cannot be disabled. Thus, if you try to set the ConnectionTimeout property to 0, the property retains its previous setting.

Setting request timeouts

The HeaderWaitTimeout metabase property specifies the amount of time (in seconds) that the server waits for the client computer to send all HTTP headers for a request (indicated by a double carriage return) before HTTP.sys resets the connection. The purpose of this property is to help impede a type of denial of service attack that attempts to exhaust connection limits and keep those connections connected. You can apply this connection timeout only at the WWW service level.

For security reasons, the HeaderWaitTimeout property cannot be disabled. Thus, if you try to set the HeaderWaitTimeout property to 0, the property retains its previous setting.

Setting response timeouts

The MinFileBytesPerSec metabase property determines the length of time that the client has to receive the server's entire response to its request. If the client computer does not receive the entire HTTP response within the interval set by the time-out value (by default, 240 bytes per second), HTTP.sys terminates the connection. You can apply this connection timeout only at the WWW service level.

Configuring the MinFileBytesPerSec metabase property prevents a client computer from sending a request for a large response (such as a file download) and then receiving the response at a maliciously slow rate that is meant to consume resources on the server and potentially interrupt service for other client computers.

The time-out period is calculated by dividing the size of the entire response (including headers) by the value of the MinFileBytesPerSec property to obtain a maximum allowable response time, in seconds. For example, a 2‑KB response (2,048 bytes) is allowed 8.5 seconds to complete if MinFileBytesPerSec has the default value of 240 bytes per second.

To accommodate very slow applications, you can disable the MinFileBytesPerSec property by setting the value to 0.

Reference to Default Time-out Settings

Additional IIS 6.0 metabase properties set time-out values for ASP, Common Gateway Interface (CGI) scripts, and Internet database connection pooling. Table 6.11 gives a summary of the metabase properties for setting timeouts and the default time-out limit for each property. For information about configuration options, see "Code Examples to Configure Metabase Properties" in IIS 6.0 Help. The final column of the table indicates which properties can alternatively be updated in IIS Manager.

Table 6.11   Default Time-out Values for IIS 6.0

Metabase Property

Default Time-Out Value

Configured in IIS Manager

AspQueueTimeout

Unlimited

 

AspScriptTimeout

90 seconds


AspSessionTimeout

20 minutes


CGITimeout

300 seconds


ConnectionTimeout

120 seconds (Web and FTP);

10 minutes (SMTP and NNTP)


HeaderWaitTimeout

None (Turned off by default.)

 

MinFileBytesPerSec1

240 bytes per second

 

PoolIdcTimeout

None (Turned off by default.)

 

1 This metabase property cannot be modified in IIS Manager, but it can be modified by adding the MinFileBytesPerSec entry to the Windows registry.

 

For more information about ASP–related properties and counters, see "Monitoring ASP Performanceiisrg_per_NURK" later in this chapter. For information about the registry path for the MinFileBytesPerSec entry, see "Global Registry Entries" in IIS 6.0 Help.

Another way to limit connections to your Web server is to use bandwidth throttling. For information, see "Throttling Bandwidth to Manage Service Availabilityiisrg_per_FCTH" later in this chapter. A related way to manage resources is to limit the number of simultaneous connections to your sites and server. For information about limiting connections, see "Limiting Connections to Manage Resourcesiisrg_per_ISHV" earlier in this chapter.

If your Web sites use large amounts of bandwidth or if you want to use bandwidth more effectively, consider enabling HTTP compression, which provides faster transmission times between IIS and compression-enabled browsers regardless of whether your content is served from local storage or a UNC resource. If your network bandwidth is restricted, HTTP compression can be beneficial unless your processor usage is already very high.

IIS provides the following compression options:

u        Static files only.

u        Dynamic application responses only.

u        Both static files and dynamic application responses.

Dynamic processing can affect CPU resources because IIS does not cache compressed versions of dynamic output. If compression is enabled for dynamic responses and IIS receives a request for a file that contains dynamic content, the response that IIS sends is compressed every time it is requested. Because dynamic compression consumes considerable CPU time and memory resources, use it only on servers that have slow network connections but CPU time to spare.

Compressed static responses can be cached and therefore do not affect CPU resources like dynamic responses do.

How HTTP Compression Works

When IIS receives a request, it checks whether the browser that sent the request is compression-enabled. (Recent versions of Microsoft® Internet Explorer and most other browsers typically send the following header if they are compression-enabled: Accept-Encoding: gzip, deflate.) IIS then determines whether the request is for a static file or for dynamic content.

If the content of the file is static, IIS checks whether the file has previously been requested and is already stored in a compressed format in the temporary compression directory. If a compressed version of the requested file is not found, IIS sends an uncompressed version of the requested file to the client browser while a background thread compresses the requested file. The newly compressed file is then stored in the compression directory, and subsequent requests for that file are serviced directly from the compression directory. In other words, an uncompressed version of the file is returned to the client unless a compressed version of the file already exists in the compression directory.

If the file contains dynamic content, IIS compresses the response as it is generated and sends the compressed response to the browser. No copy of the file is cached by the Web server.

The performance cost of compressing a static file is modest and is typically incurred only once, because the file is then stored in the temporary compression directory. The cost of compressing dynamically generated files is somewhat higher because the files are not cached and must be regenerated with each request. The cost of expanding the file at the browser is minimal. Compressed files download faster, which makes them particularly beneficial to the performance of any browser that uses a network connection with restricted bandwidth (a modem connection, for example).

When you enable HTTP compression, compressed files are given a default expiration date of Jan. 1, 1997. This expiration date prevents proxy servers from serving cached copies of compressed files to browsers that are not compression-enabled. This expiration date also forces browsers to return to the server for a fresh copy of the file when the user makes a new request instead of displaying a cached copy of the file. When you enable HTTP compression, the default settings for the HcExpiresHeader, HcCacheControlHeader, and HcSendCacheHeaders metabase properties ensure that older clients and proxy servers do not attempt to cache compressed files. Before you change these settings, see "Metabase Property Reference" in IIS 6.0 Help for information about these and related metabase properties.

Determining Whether HTTP Compression Will Improve Performance

If your server generates a large volume of dynamic content, consider whether the additional processing cost of HTTP compression is one that you can reasonably afford. If the % Processor Time counter is already 80 percent or higher, enabling HTTP compression is not recommended.

To evaluate how much of your processor is typically being used, follow these steps:

1.         Establish a baseline for your processor usage by using System Monitor to log the following counters over several days. If you use Performance Logs and Alerts, you can log the data to a database and then query the data, examining the results in detail.

u        Processor\% Processor Time. This counter has a total instance and a separate instance for each processor in the system. If your server has more than one processor, you need to watch the individual processors as well as the total to discover any imbalance in the workload.

u        Network Interface\Bytes Sent/sec. Counters for the Network Interface performance object display the rate at which bytes are transmitted over a TCP/IP connection by monitoring the counters on the network adapter. For information about additional counters to monitor for this object, see Table 6.8.

2.        Enable compression, and continue to log the values for these counters for an extended period — preferably for several days — so you have a good basis for comparison.

Collect a broad sample to determine how compression affects various aspects of performance. Conduct the following tests:

u        Enable static compression only, dynamic compressions only, and both.

u        Change the list of files that you use for compression testing for both static and dynamic content.

u        Vary the compression level. Try this on all content types.

3.        Compare the data from monitoring with and without compression, and with different types of compression, different compression levels, and different files.


Important

If you see signs of blocking or bottlenecking during the preceding testing, promptly stop the test. A significant drop in the value of either counter indicates that performance with compression enabled has decreased relative to performance without compression enabled.


Choosing Compression Options

When you configure HTTP compression by using IIS Manager, IIS 6.0 automatically applies the default settings shown in Table 6.12. You can configure custom settings for each compression option by editing the metabase or alternatively — in the case of the compression directory — by using IIS Manager.

Table 6.12   Default Settings When HTTP Compression Is Enabled

Compression Options

File Type

Default Configuration

Configuration Method

File types compressed

Static

.txt, .htm, and .html

Metabase

Dynamic

.exe, .dll, and .asp

Metabase

Compression schemes

Static

Both gzip and deflate

Metabase

Dynamic

Both gzip and deflate

Metabase

Compression level

Static

10

Metabase

Dynamic

0

Metabase

Compression directory

Static

Size: 95 MB

Location1: %Windir%\IIS Temporary Compressed Files

Metabase or IIS Manager

Dynamic

No directory2

N.A.

1 The compression directory must reside on an NTFS file system volume.

2 When dynamic files are compressed, they are not cached.

 

If the default HTTP compression configuration does not meet the needs of your organization, you can make the following changes to the configuration:

u        Specify additional file types to compress. Edit the HcFileExtensions metabase property (for static files) and the HcScriptFileExtensions metabase property (for dynamic files) to apply compression to additional file types. Add only compressible files types to your compression scheme because trying to compress an already compressed file — such as .jpg, .mp3, or .zip files — wastes processing time.

u        Enable or disable the gzip or deflate compression scheme. When you use IIS Manager to enable compression, IIS enables both compression schemes (gzip and deflate), so that IIS can apply whichever compression scheme the client requests. You can edit the metabase to specify that only a particular compression scheme is used. If you disable the only compression scheme that a client supports, the server replies with an uncompressed file.


Note

Disabling either the gzip or deflate compression schemes can have unintended consequences, such as not compressing responses to a particular browser. For maximum compatibility, it is recommended that you leave both compression schemes enabled.


u        Change the level of compression for static or dynamic files. Compression levels range from 0 through 10. Higher compression levels produce smaller compressed files but use more CPU and memory. Lower compression levels produce slightly larger compressed files, but with less impact on CPU and memory usage. To configure a compression level other than 10 for static files and other than zero for dynamic files, edit the HcOnDemandCompLevel and HcDynamicCompressionLevel metabase properties.

For dynamic compression, increasing the compression level can significantly increase CPU usage. The default compression level of zero uses the least amount of CPU resources and can increase performance if network bandwidth is adequate. Raise the dynamic compression level above zero only if you need more network bandwidth and have sufficient CPU capacity to handle the extra load.

u        Change the location or size of the compression directory. To change the location and size of the compression directory for static files, edit the HcCompressionDirectory, HcDoDiskSpaceLimiting, and HcMaxDiskSpaceUsage metabase properties.

The procedures in the following sections tell how to enable HTTP compression and make the following configuration changes:

u        Use IIS Manager to enable HTTP compression, using the default HTTP compression configuration, for static and dynamic files.

u        Configure compression at specific levels of the metabase (for example, compression at the Web site level).

u        Specify which file types to compress and the compression scheme to apply.

u        Specify the location and size of the compression directory.

u        Disable HTTP compression for requests that come through certain proxy servers.

Compression Strategies

When the CPU of your server is not heavily loaded, the simplest compression strategy is to enable static and dynamic compression for all of the sites and site elements (directories and files) on the server. This is known as global HTTP compression. However, when the CPU load of your server is high, you might not want to enable compression for all of the sites and site elements on the server.

Depending on CPU usage, there are two strategies for fine tuning which sites and site elements are compressed:

u        Enable compression globally, and then disable compression selectively for specific sites or site elements.

u        Leave global compression disabled, and then enable compression selectively for specific sites or site elements.

Enabling Global HTTP Compression

Important

After enabling HTTP compression (either by using IIS Manager or by editing the metabase), you must restart IIS for the change to take effect.


When you enable HTTP compression by using IIS Manager, IIS applies compression according to the default settings shown in Table 6.12. With the exception of the location and size of the compression directory, you cannot change the default settings by using IIS Manager. Instead, you must edit the metabase to change the default settings.


 


To enable global HTTP compression by using IIS Manager

1.         In IIS Manager, double-click the local computer, right-click the Web Sites folder, and then click Properties.

2.        Click the Service tab, and in the HTTP compression section, select the Compress application files check box to enable compression for dynamic files.

3.        Select the Compress static files check box to enable compression for static files.

4.        In the Temporary directory box, type the path to a local directory or click Browse to locate a directory. Once a static file is compressed, it is cached in this temporary directory until it expires, or the content changes. The directory must be on the local drive of an NTFS–formatted partition. The directory cannot be compressed or shared, and the access control lists (ACLs) for the directory must include Full Control access to the identity of the application pool or to the IIS_WPG group.

5.        Under Maximum temporary directory size, click a folder size option. If you specify a maximum size under Limited to (in megabytes) (the default setting is 95 MB), then when the limit is reached, IIS automatically cleans up the temporary directory by applying the "least recently used" rule.

6.        Click Apply, and then click OK.


To enable global HTTP compression by using Adsutil.vbs

1.         Open a command prompt.

2.        To enable dynamic compression, type the following at the command prompt and then press ENTER:

cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true

3.        To enable static compression, type the following at the command prompt and then press ENTER:

cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true

Configuring HTTP Compression for Individual Sites and Site Elements

All of the compression configurations discussed so far are located under W3SVC/Filters/Compression in the metabase and are used to apply global HTTP compression, which is applied by using IIS Manager or by using one of the metabase properties that are used for global compression (beginning with Hc…). IIS 6.0 offers two new metabase properties, DoStaticCompression and DoDynamicCompression (beginning with Do…), which can be used to enable or disable compression at the individual site and site element levels. Use these two new properties to apply compression to individual namespaces. Hence, you can enable global compression by using IIS Manager or the Hc… global properties and then disable one of the Do… properties (or vice versa) to obtain compression at a specific location in the IIS metabase.


Important

You must be a member of the Administrators group on the local computer to run scripts and executables, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile/User:MyMachine\Administrator cmd to open a command window with administrator rights and then type cscript.exe ScriptName (including the full path with parameters, if any).


To enable static compression for a single directory, first ensure that global static compression is disabled and then enable static compression at that directory. For example, to enable static compression for a directory at http://www.contoso.com/Home/StyleSheets, perform the following steps:

1.         Disable global static compression by executing the following command at a command prompt:

adsutil set w3svc/filters/compression/parameters/HcDoStaticCompression false

2.        Enable static compression at this directory by executing the following command at a command prompt:

adsutil set w3svc/1/root/Home/StyleSheets/DoStaticCompression true

To disable static compression for a single directory, first ensure that global static compression is enabled and then disable static compression at that directory. For example, to enable static compression for a directory at http://www.contoso.com/Home/StyleSheets, perform the following steps:

1.         Disable global static compression by executing the following command at a command prompt:

adsutil set w3svc/filters/compression/parameters/HcDoStaticCompression true

2.        Enable static compression at this directory by executing the following command at a command prompt:

adsutil set w3svc/1/root/Home/StyleSheets/DoStaticCompression false

Specifying File Types and Compression Schemes by Editing the Metabase

After enabling HTTP compression, you can use the Adsutil.vbs command-line utility (located in the systemroot\Inetpub\Adminscripts folder) to edit the metabase, specifying which static or dynamic file types to compress and which compression scheme to apply.

Using Adsutil.vbs, you can customize HTTP compression in the following ways:

u        Apply the gzip or deflate compression scheme, or both. To apply both schemes, you must execute a separate set command for each compression scheme.

u        Customize the file types to which both static and dynamic compression are applied. You must execute a separate set command for each compression type. If you use IIS Manager to enable compression and you then use Adsutil.vbs to specify specific static or dynamic file types, you replace any default values that were applied by IIS Manager.


Note

For compression to be performed, the HcDoStaticCompression metabase property must be set to true (for static compression) and the HcDoDynamicCompression metabase property must be set to true (for dynamic compression). You can set these by using IIS Manager or Adsutil.vbs. For instructions, see the procedures in the preceding section.


The following syntax enables compression at the W3SVC level (which means it is applied to all Web sites and virtual directories on the Web server):

cscript.exe adsutil.vbs set W3svc/Filters/Compression/{GZIP|DEFLATE}/
{HcFileExtensions "StaticFileType" ...}|{HcScriptFileExtensions "DynamicFileType" ...}

You must restart the WWW service before any changes take effect. For information about restarting a service, see "Common Administrative Tasksiisrg_tas_LPPR" in this book. Table 6.13 describes the parameters for customizing file types and compression schemes.

Table 6.13   Parameters for Setting Compression Schemes and File Types for HTTP Compression

Parameter

Description

GZIP|DEFLATE

Specifies which compression scheme (either gzip or deflate) to apply to the specified file types. To enable both compression schemes, you must run this command once for each compression scheme. For maximum compatibility, leave both compression schemes enabled.

HcFileExtensions "StaticFileType" ...

Specifies which static file types to apply the compression scheme to — for example, .txt, .js, .css, .doc, or .xls files. To specify a file type, enclose the file name extension (without the leading period) in quotation marks. Separate multiple file types with a space. This parameter cannot be executed together with the HcScriptFileExtensions "DynamicFileType" parameter.

HcScriptFileExtensions "DynamicFileType" ...

Specifies which dynamic file types to apply the compression scheme to — for example, .exe, .dll, or .asp files. To specify a file type, enclose the file name extension (without the leading period) in quotation marks. Separate multiple file types with a space. This parameter cannot be executed together with the HcFileExtensions "StaticFileType" parameter.

Important: Setting the HcScriptFileExtensions parameter to an empty string can adversely affect your server's performance. If this parameter is empty, all dynamic responses are sent compressed. In addition, any static file type not specified in HcFileExtensions is dynamically compressed and therefore not cached.

 

For example, the following command uses a deflate compression scheme to apply static compression at the W3SVC level to text files (.txt) and cascading style sheets (.css):

cscript.exe adsutil.vbs set w3svc/Filters/Compression/DEFLATE/HcFileExtensions "txt" "css"

Specifying the Location and Size of the Compression Directory for Static Compression

Three metabase properties enable you to change the location of the default directory for static compression and to limit its size.

Changing the location of the compression directory

The HcCompressionDirectory metabase property specifies the folder where compressed versions of static files are temporarily cached. By default, the compression directory is at %Windir%\IIS Temporary Compressed Files.

Due to a number of differences between NTFS and FAT volumes — such as differences in time stamping and access control mechanisms, and the efficiency with which NTFS handles directories that contain large numbers of files — the compression directory must reside on an uncompressed and unshared NTFS volume. In addition, the access control lists (ACLs) for the folder must include Full Control access to the identity of the application pool or to the IIS_WPG group. If a requested file resides on an NTFS volume and the compression directory is on a FAT volume, IIS does not perform HTTP compression on that file.

Setting a size limit for the compression directory

In addition, you can configure the HcDoDiskSpaceLimiting and HcMaxDiskSpaceUsage metabase properties to limit the amount of disk space that all files in the compression directory can occupy. HcDoDiskSpaceLimiting enables disk space limiting. If it is set to true, IIS limits compressed files to no more than the number of bytes specified by HcMaxDiskSpaceUsage. After the limit is reached, compressed files are removed from the compression directory on a "least recently used" basis. If HcDoDiskSpaceLimiting is set to false, no disk space limit is enforced for the compression directory.

HcDoDiskSpaceLimiting is relevant only if you have set the property HcDoOnDemandCompression to true. For more information about these metabase properties, see "Metabase Property Reference" in IIS 6.0 Help.


Important

Limiting the use of disk space has a significant impact on performance because additional overhead is required to check for the limit. Use this feature only when you lack adequate disk space to cache all content files on your Web server.


Disabling HTTP Compression for Requests That Come Through Certain Proxy Servers

Certain HTTP proxy servers, including some advertised as HTTP 1.1–compliant, do not handle the caching of compressed objects correctly. The HcNoCompressionForProxies metabase property allows you to disable the HTTP 1.1 response for compression requests that come through proxy servers.

In addition, you can use the HcNoCompressionForHttp10 metabase property to disable compression for requests that contain an HTTP 1.0 version number. HTTP 1.0, as described in RFC 1945, "Hypertext Transfer Protocol — HTTP/1.0," provides a minimal level of support for certain types of compression. However, some confusion exists concerning HTTP 1.0 compression, especially with regard to proxy servers. To minimize the chance of inappropriately returning a compressed file to a client that cannot decompress it, you can use the HcNoCompressionForHttp10 metabase property to disable compression in questionable scenarios.

For more information about the many metabase properties that you can set when configuring HTTP 1.1 compression, including a complete list of all the properties you can set, see "IIsCompressionSchemes (ADSI)" in IIS 6.0 Help.

If the network or Internet connection used by your Web server is also used by other services, such as e-mail or news, you can limit the bandwidth used by your Web server so that the server is available for those other services. If your Web server hosts more than one Web site, you can individually throttle the bandwidth used by each site. However, keep in mind that the IPv6 network traffic handled by your Web sites is not throttled.

Bandwidth throttling uses Packet Scheduler to manage when data packets are sent. When you configure a site to use bandwidth throttling by using IIS Manager, Packet Scheduler is automatically installed, and IIS automatically sets bandwidth throttling to a minimum of 1024 kilobytes per second (KBps). However, if you use another method, such as Active Directory® Service Interfaces (ADSI) or WMI, you must install Packet Scheduler in order for bandwidth throttling to work correctly.


To enable Packet Scheduler

1.         From the Start menu, click Control Panel, click Network Connections, right-click any of the listed connections, and then click Properties.

2.        On the General tab under This connection uses the following items, click any of the listed items, and then click Install.

3.        In the Select Network Component Type dialog box, click Service, and then click Add.

4.        In the Select Network Service dialog box, click QoS Packet Scheduler, and then click OK to close all open dialog boxes.

When using ADSI or WMI to configure bandwidth throttling, you must set bandwidth throttling to 1024 KBps or more, because Packet Scheduler cannot enforce bandwidth throttling settings below that level. Also, you need to uninstall Packet Scheduler if it is not in use by individual sites or the WWW service as a whole.

Determining When and Where to Use Bandwidth Throttling

Before enabling bandwidth throttling, determine your Web server's typical load by using System Monitor to log the following counters over several days:

u        Bytes Total/sec or Current Bandwidth counter on the Network Interface object. To compare incoming and outgoing traffic, examine both Bytes Sent/sec and Bytes Received/sec.

u        Compare the values from the Network Interface object counters with the total bandwidth of your network connection.

If you use Performance Logs and Alerts, you can log the data to a database and then query the data, examining the results in detail.

For a typical load, your server should use no more than 50 percent of its total available bandwidth. If your server is subject to large peaks in use, keep your typical load lower than 50 percent. The remaining bandwidth can be used during peak periods.

If testing of your servers' typical loads shows that a server or a particular site is consistently using more than 50 percent of the available bandwidth, use the procedures that follow to throttle bandwidth.

In addition, before you set global bandwidth throttling, be sure that you understand the following:

u        Individual sites throttle bandwidth according to their established maximum; the global setting limits the total network bandwidth that is available for all unthrottled Web sites on a server. Setting a global WWW service maximum bandwidth does not override established bandwidth maximums for individual Web sites on the server.

u        Global bandwidth throttling settings for the WWW service do not affect FTP sites or the FTP service as a whole.

Enabling Bandwidth Throttling

The following procedures tell how to globally enable bandwidth throttling for the WWW service or to enable bandwidth throttling for a specific Web site, and how to disable bandwidth throttling on an individual site in order to override global bandwidth throttling.


To globally throttle WWW service bandwidth

1.         In IIS Manager, expand the local computer, right-click the Web Sites folder, and then click Properties.

2.        On the Performance tab, under Bandwidth throttling, select the Limit the total network bandwidth available for all Web sites on this server check box.

3.        In the Maximum bandwidth (in kilobytes per second) box, type the maximum number of kilobytes per second that you want to allow for each site contained in the folder.

4.        Click Apply, and then click OK.

 


To throttle the bandwidth used by an individual Web site

1.         In IIS Manager, expand the local computer, expand the Web Sites folder, right-click the Web site, and then click Properties.

2.        On the Performance tab, under Bandwidth throttling, select the Limit the network bandwidth available to this Web site check box.

3.        In the Maximum bandwidth (in kilobytes per second) box, type the maximum number of kilobytes per second that you want the site to use.

4.        Click Apply, and then click OK.

5.        The following procedure tells how to disable bandwidth throttling for an individual site. The procedure is slightly different if you are overriding global bandwidth throttling. Either task can also be performed by using ADSI or WMI to update the MaxBandwidth metabase property for the site.

 


To disable bandwidth throttling on an individual site

u        If global bandwidth throttling is not in effect, on the Performance tab, under Bandwidth throttling, clear the Limit the network bandwidth available to this Web site check box. Alternatively, you can set the MaxBandwidth metabase property to –1 by using ADSI or WMI.

u        If global bandwidth throttling is in effect, but you want an individual site to have virtually unlimited bandwidth, on the Performance tab, under Bandwidth throttling, do not clear the Limit the network bandwidth available to this Web site check box (the global setting automatically applies to the individual site when the check box is cleared). Instead, enter a very high number in the Maximum bandwidth (in kilobytes per second) box. Alternatively, you can set the MaxBandwidth metabase property to –2 by using ADSI or WMI.

 


Note

Bandwidth throttling is not supported for requests that come to a site by means of an IPv6 address. The MaxBandwidth metabase property does not affect IPv6 network traffic.


For more information about administering IIS with ADSI or with WMI, see "Using the IIS ADSI Provider" or "Using the IIS WMI Provider" in IIS 6.0 Help. For more information about configuring the MaxBandwidth metabase property, see "Metabase Property Reference" in IIS 6.0 Help.

IIS 6.0, when running in worker process isolation mode, offers several features that you can use in addition to the QoS feature to better manage your systems' resources:

u        Use Web gardens to enhance performance.

u        Conserve processor resources by using idle timeout.

u        Enable CPU monitoring to conserve processing time.

u        Assign processor affinity to better use CPU caching.

Using Web Gardens to Enhance Performance

If the server is running in worker process isolation mode, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. Creating a Web garden for an application pool enhances performance and reliability by providing the following enhancements:

u        Robust processing of requests. When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.

u        Reduced contention for resources. When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. The round-robin scheme smoothes out workloads and reduces contention for resources that are bound to a worker process.

For more information about Web gardens, including how to configure them, see "Running IIS 6.0 as an Application Serveriisrg_was_OVERVIEW" in this book.

Conserving Processor Resources by Using Idle Timeout

If the server is running in worker process isolation mode, you can conserve system resources by terminating idle worker processes; that is, you can configure an application pool's worker process to shut down after a specified period of inactivity. Use this feature to better manage your resources when the processing load is heavy, when identified worker processes are consistently idle, or when new processing space is not available. If an application pool times out because the inactivity of its worker process exceeds a configured limit for idle timeout, and if HTTP.sys then receives a request for the idle application pool, the WWW service starts a new worker process to replace the one that timed out.

For more information about configuring idle timeout for a worker process, see "Running IIS 6.0 as an Application Serveriisrg_was_OVERVIEW" in this book.

Enabling CPU Monitoring to Conserve Processing Time

Through CPU monitoring of application pools, you can monitor the CPU usage of worker processes and, if you configure it to do so, automatically shut down worker processes that consume large amounts of CPU processing time. CPU monitoring logs and throttles only the applications that are isolated in a process that is separate from IIS; hence, this feature is only available when your server is running in worker process isolation mode.

When you configure CPU monitoring for an application pool, you can choose from two monitoring options:

u        Perform only event logging. When the CPU usage for an application pool exceeds the Maximum CPU use limit, the WWW service writes an error to the Windows event log. The log entry identifies the specific worker process and the application pool that exceeded the CPU limit.

u        Log events, and also shut down the unhealthy application pool. After an application pool reaches the configured Maximum CPU use limit, CPU monitoring writes an error to the event log and shuts down the application pool. The application pool remains down until the CPUResetInterval time limit expires, at which time the application pool restarts. If any requests are received while the application pool is stopped, HTTP.sys returns a 503 error (Server Too Busy).

For more information about CPU monitoring, including how to configure it, see "Running IIS 6.0 as an Application Serveriisrg_was_OVERVIEW" in this book.

Obtaining more detailed CPU monitoring

If your Web server is running the Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, operating system, you can use the Windows System Resource Manager to monitor different types of CPU activity more closely. With this feature, you can control how CPU and memory resources are allocated to applications, services, and processes. However, Windows System Resource Manager cannot manage system resources correctly if the computer is already being managed by another resource manager, such as IIS CPU monitoring. For best results, if you use Windows System Resource Manager, do not use any other resource manager on that computer.

For more information about Windows System Resource Manager, see the Windows System Resource Manager — Fast Facts link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

With memory, more is almost always better. However, just adding more RAM to your server does not optimize performance. You must first determine whether you are making good use of the memory that the server has.

The biggest performance gains with IIS occur when you resolve issues related to insufficient memory. Before changing your hardware configuration, rule out memory problems. Monitor memory first to verify that your server has enough memory, and then move on to other parts of your server environment. Problems caused by memory shortages can often appear to be problems in other parts of the system.

Minimum Memory Requirements for IIS 6.0

To run IIS 6.0 with the Windows Server 2003 operating system, a dedicated Web server must have a minimum of 128 MB of RAM. However, your server might require more RAM to handle the resource needs of custom applications. If your custom applications require large amounts of memory, provide 256 MB or more of RAM. Additional memory is particularly beneficial for e‑commerce sites, sites with a lot of content, and sites with a high volume of traffic.

Memory Management and Memory Allocation in Windows Server 2003

In order to use memory most efficiently, the Windows Server 2003 memory system is largely self-tuning. Similarly, IIS 6.0 regulates the size of the IIS object cache. Therefore, the primary purpose of monitoring memory on a Windows Server 2003–based server running IIS 6.0 is not to adjust the size of each memory component, but rather to make sure that the system as a whole has enough memory and is using it efficiently.

The largest "chunk" of activity in Windows Server 2003 is a process. The physical RAM available to a process is known as its working set. If the needs of a process exceed its working set — that is, if the process is not able to store all its code and frequently used data in RAM — some of the information is stored elsewhere, usually on disk as virtual memory.

Storing information on disk instead of in memory increases disk activity, which slows down the server. Some memory contains information that is frequently used, and sending that data to disk instead of retaining it in memory can degrade performance.

In addition, a section of system memory, known as pool memory, is reserved for use by the operating system. Pool memory is either paged or nonpaged. Nonpaged pool is the section of pool memory that is not pageable. Data in a nonpaged pool is always stored in physical memory and never saved to the disk. This section is usually reserved for device drivers or other critical system components that cannot wait for memory to be paged. Paged pool is the section of pool memory that can be managed in the same way as other virtual memory — that is, it is pageable in that inactive memory can reside on the disk, and the current or active memory can reside in physical memory.

Within each process, Windows Server 2003 uses threads to accomplish particular tasks. The memory occupied by threads is part of the working set of the process, except for some special threads that run in nonpageable memory. Threads that service connections in IIS 6.0, for example, cannot be paged.

This section tells how to monitor various aspects of overall server memory — available memory, paging, use of the file system cache, the size of paging files, the IIS working set, and disk I/O — and, based on your observations, how to optimize memory usage.

Use System Monitor to check the values of the counters described in the following sections. This will help you determine if the current amount of memory on your server is sufficient for your needs.

To evaluate memory usage on your Web server, look at available memory, paging, the size of the file system cache, the size of the paging files, the size of the components of the IIS 6.0 working set, and disk I/O.

Monitor the counter in Table 6.14 to determine whether the server has performance bottlenecks associated with memory.

Table 6.14   Counter for Monitoring Available Memory

Object\Counter

Value

Memory\Available Bytes

The amount of physical memory, in bytes, available to processes running on the computer. This counter displays the last observed value only; it is not an average.

 

Compare the total physical memory that is available to Windows Server 2003 with the available memory remaining when all server services are running. To gather reliable data, log this value over time, being sure to include periods of peak activity. Try to reserve at least 10 percent of available memory for peak use.

If a process requests a page in memory and the system cannot find the page at the requested location, a page fault occurs. If the page is elsewhere in memory, the fault is a soft page fault. If the page must be retrieved from disk, the fault is a hard page fault. Most processors can handle large numbers of soft page faults without consequence. However, hard page faults can cause significant delays. Continuous high rates of disk paging indicate a memory shortage.

Table 6.15 lists the counters that are available for monitoring hard and soft page faults.

Table 6.15   Counters for Monitoring Page Faults, Pages Input, and Page Reads

Object\Counter

Value

Memory\Page Faults/sec

The overall rate at which the processor handles both hard and soft page faults.

Memory\Pages Input/sec

The total number of pages read from disk to resolve hard page faults.

Memory\Page Reads/sec

The number of times that the disk was read to resolve hard page faults.

Memory\Transition Faults/sec

The rate at which page faults are resolved by recovering pages without incurring additional disk activity. Transition faults, which measure soft page faults, are counted in numbers of faults because only one page is faulted in each operation; the number of transition faults is equal to the number of pages faulted.

 

Hard page faults increment the Page Faults/sec counter (which reports the rate of hard and soft page faults combined) in addition to the Pages Input/sec and Page Reads/sec counters (which report the rate of hard page faults only). The Transition Faults/sec counter is only incremented by soft page faults.

The value of the Memory\Pages Input/sec counter (the number of pages read from disk as a result of hard page faults) will be greater than or equal to the value of Page Reads/sec (the number of times the disk was read as a result of hard page faults), and can give you a good idea of your hard page fault rate. If these numbers are low, your server is responding to requests quickly. If these numbers are high, investigate whether you have dedicated too much memory to the caches, leaving too little memory for the rest of the system. If reducing cache sizes does not improve system performance, you might need to increase the amount of RAM on your server.

Monitor the counters in Table 6.16 to determine whether a server has a performance bottleneck associated with the size of the file system cache. These counters display the last observed value only; they do not display an average value.

Table 6.16   Counters for Monitoring the File System Cache

Object\Counter

Value

Memory\Cache Bytes

The current size, in bytes, of the file system cache. By default, the cache uses up to 50 percent of available physical memory. The counter value is the sum of Memory\System Cache Resident Bytes, Memory\System Driver Resident Bytes, Memory\System Code Resident Bytes, and Memory\Pool Paged Resident Bytes.

Memory\System Cache Resident Bytes

The current size, in bytes, of the pageable operating system code in the file system cache. This value includes only current physical pages and excludes any virtual memory pages not currently resident.

Memory\System Driver Resident Bytes

The current size, in bytes, of the pageable physical memory in use by device drivers. This represents the working set (physical memory area) of the drivers. This value is a component of Memory\System Driver Total Bytes.

Memory\System Code Resident Bytes

The current size, in bytes, of the operating system code currently in physical memory that can be written to disk when it is not in use. This value is a component of Memory\System Code Total Bytes.

Memory\Pool Paged Resident Bytes

The current size, in bytes, of the paged pool. The paged pool is an area of system memory (physical memory used by the operating system) reserved for objects that can be written to disk when they are not in use. The space that is used by the paged and nonpaged pools is taken from physical memory; thus, a pool that is too large denies memory space to processes.

 

The value of the Memory\System Cache Resident Bytes counter equals the System Cache value shown on the Performance tab in Task Manager. As a result, this value can be smaller than the actual amount of virtual memory in use by the file system cache.

Windows Server 2003 automatically trims the cache when memory is scarce and enlarges the cache when memory is ample. Use the Memory\Cache Bytes counter to monitor the size of the file system cache. A log of cache size readings reveals how the size of the file system cache changes over time. Compare the log data to a measure of general memory availability, such as data from the Memory\Available Bytes counter. By monitoring these counters and watching the trends, you can expose memory shortages in a server.

When examining the logs, note when the cache is smallest. Track how small the cache gets and how often its size is reduced. Also, note how much system memory is available when the cache size is reduced. By watching these trends, you can begin to associate the size of the cache with the server's performance. For example, if performance degrades when the cache is large, consider adding RAM. If performance degrades when the cache is small, consider increasing the time interval during which objects remain in the cache before being flushed. For more information about monitoring and tuning IIS file cache, see "Web Server Scalabilityiisrg_sca_OVERVIEW" in this book.

The counters in Table 6.17 are useful in examining paging file usage. Paging files store pages of memory used by a process that are not contained in other files. Paging files are shared by all processes, and the lack of space in paging files can prevent processes from allocating memory.

Table 6.17   Counters for Monitoring Page Files

Object\Counter

Value

Process\Page File Bytes

The current amount of virtual memory, in bytes, that this process has reserved for use in the paging files.

Process\Page File Bytes Peak

The maximum amount of virtual memory, in bytes, that this process has reserved for use in the paging files.

Paging File\% Usage

The percentage of the Page File instance that is in use.

Paging File\% Usage Peak

The peak usage of the Page File instance, expressed as a percentage of total file size.

 

Windows Server 2003 creates a paging file (with the file name Page File) on the system drive. You can create a paging file on each logical disk. By striping a paging file across separate physical drives, you can improve paging file performance by using drives that do not contain your site's content or log files.

You can change the sizes of existing paging files. The larger the paging file, the more memory the system commits to it. Be sure that the paging file on the system drive is at least twice the size of the physical memory, so that the system can write the entire contents of RAM to disk if the system unexpectedly locks up or shuts down.

If free memory on the computer is above a threshold, pages are left in the working set of a process even if they are not in use. When free memory falls below that threshold, pages are trimmed from working sets. If the trimmed pages are later needed, they are soft-faulted back into the working set before leaving main memory.

When available memory falls below about 4 MB, the system attempts to make more memory available by taking memory away from the working sets of processes. This strategy increases the rate of page faults, because each process must now retrieve data that was once in its working set either from disk or from elsewhere in memory. When the rate of page faults for a particular process rises, however, the system attempts to expand the working set of that process to lower the page fault rate. As the system tries to maintain this balance, the size of the working set of each process fluctuates accordingly.

The Process\Working Set counters measure the number of memory pages that each process uses. If the system has sufficient memory, it can maintain enough space in the working set so that IIS 6.0 rarely must perform disk operations. One indicator of memory sufficiency is how much the size of the process working set fluctuates in response to general memory availability on the server. Significant fluctuation can indicate a lack of available memory.

The system's memory pools hold objects created and used by applications and the operating system. The contents of the memory pools are accessible only in privileged mode — that is, only the kernel of the operating system can directly use the memory pools; user processes cannot.

Table 6.18 describes the counters that are available for monitoring the IIS 6.0 working set.

Table 6.18   Counters for Monitoring the IIS 6.0 Working Set

Object\Counter

Value

Memory\Pool Paged Bytes

Memory\Pool Non-paged Bytes

Pool Paged Bytes and Pool Non-paged Bytes monitor the pool space for all processes on the server.

Process(W3wp1)\Virtual Bytes

Process(Inetinfo)\Virtual Bytes

The amount of virtual address space, in bytes, reserved directly by IIS, either by the Inetinfo.exe process (where IIS runs when set to IIS 5.0 isolation mode) or by the W3wp.exe process (where isolated or pooled applications run when IIS is set to worker process isolation mode) instantiated on your server.

Process(W3wp1)\Working Set

Process(Inetinfo)\Working Set

Size, in bytes, of the working set of the W3wp.exe or Inetinfo.exe process. These counters display the last observed value, not an average over time.

1 Monitor the W3wp instance if you are running your Web server in worker process isolation mode. If you are running your server in IIS 5.0 isolation mode, monitor either the Inetinfo instance (for in-process applications) or the Dllhost instance (for out-of-process applications).

 

Important

You can run IIS 6.0 in one of two request processing models: worker process isolation mode and IIS 5.0 isolation mode. IIS typically performs better while running in worker process isolation mode, although results depend on a variety of factors, including the design of your applications. Also note that each mode uses different instances of a counter to monitor performance. For more information about the two request processing models, see "Running IIS 6.0 as an Application Serveriisrg_was_OVERVIEW" in this book.


Be sure that you monitor Process\Working Set counters for all instances of W3wp.exe (the component that hosts the worker process when IIS runs in worker process isolation mode) on your server; otherwise, you might obtain an inaccurate reading of the virtual memory used by IIS.

You can use the Memory\Available Bytes counter (in Table 6.14) as an indicator of memory availability and the Process\Working Set counters (in Table 6.18) as an indicator of the size of the IIS 6.0 working set. These counters display the last value observed, rather than an average, so be sure to examine data collected over time.

Monitoring Disk I/O

IIS 6.0 writes its logs to disk, so there is almost always some activity, even when requests are processed out of the cache 100 percent of the time. Under ordinary circumstances, disk activity other than that generated by logging might indicate a problem in other areas. For example, if your server has insufficient RAM, you see lots of disk activity because many hard page faults are occurring.

Under certain conditions, disk activity is normal. Examples include a large site that serves more content than your server can cache and any site that serves large amounts of static content that is not cacheable. You are also likely to notice lots of disk activity if your server hosts a database or if your users request many different Web pages.

Typically, you use the Physical Disk counters in Table 6.1 to watch for spikes in the number of disk reads when the server is busy. If the server has enough RAM, most connections result in cache requests, unless the server also hosts a database and clients are making dissimilar queries, which precludes caching.

If the server does not host any application or service that is obviously disk-intensive, but you see lots of disk activity anyway, you need to check RAM use immediately to make sure that the server has enough memory.

Servers running IIS 6.0 benefit from ample physical memory. Generally, the more memory that you add, the more the servers use and the better they perform. IIS 6.0 requires a minimum of 128 MB of memory; at least 256 MB is recommended. If you are running memory-intensive applications, your server might require much more memory to run optimally — more than the recommended 256 MB of memory.

Adding RAM to your system is not the only option, however. The following methods can be used to optimize memory performance without adding memory.

Improve Data Organization

To improve the performance of the file system cache, keep related Web files on the same logical partitions of a disk.

Use Disk Defragmenter to consolidate fragmented files and folders on the server's hard disk so that each occupies a single, contiguous space on the volume. As a result, the system can gain access to files and folders and save new ones more efficiently.

Increase the Efficiency of High-Traffic Web Sites

Evaluate your high-traffic Web sites to find ways to increase their efficiency. For more information about creating efficient Web sites, see "Creating a More Efficient Web Siteiisrg_per_TLBK" later in this chapter.

Try Disk Mirroring or Striping

The optimum configuration is to have enough physical memory to hold all static Web pages. However, if pages must be retrieved from disk, use mirroring or striping to make reading from disk sets faster. In some cases, a caching disk controller is helpful. For more information about mirrored or striped volumes, see "Using mirrored volumes" or "Using striped volumes" in Help and Support Center for Windows Server 2003.

Add or Enlarge Paging Files

Add paging files, or increase the size of existing ones. Windows Server 2003 creates one paging file on the system disk, but you can also create a new paging file on each logical partition of each disk. By striping a paging file across separate physical drives, you can improve paging file performance by using drives that do not contain your site's content or log files.

You can change the sizes of existing paging files. The larger the paging file, the more memory the system commits to it. Be sure that the paging file on the system drive is at least twice the size of the physical memory, so that the system can write the entire contents of RAM to disk if the system unexpectedly locks up or shuts down.

For information about resizing paging files, see "Change the size of the virtual memory paging file" in Help and Support Center for Windows Server 2003.

Retime the IIS Object Cache

Consider shortening the period of time that an unused object remains in the cache, or lengthening the time that a used object remains in the cache, by adding the ObjectCacheTTL entry to the registry.


Caution

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the <A HREF="http://go.microsoft.com/fwlink/?LinkID=4543" TARGET="_blank">Registry Reference</A> on the Windows Server 2003 Resource Kit companion CD or on the Web at http://www.microsoft.com/reskit.


The value of ObjectCacheTTL controls the static file cache by specifying the Time To Live (TTL), which sets the length of time that objects are held in cached memory. If an object in the memory cache has not been referenced for the defined period, that object is phased out of the cache.

The default value is 30 seconds. If system memory is limited or if the contents of the server are dynamic, you can use a lower TTL to prevent system memory from being used to cache a large number of volatile objects. Setting the ObjectCacheTTL entry to unlimited disables the object-cache scavenger and allows cached objects to remain in the cache until the cached object changes. Disabling the cache scavenger is useful if your server has ample system memory and your data is relatively static.

Use the following procedure to reset the time that an unused object remains in the object cache by adding the ObjectCacheTLL entry to the registry.


Important

You must be a member of the Administrators group on the local computer to run scripts and executables, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile /User:MyMachine\Administrator cmd to open a command window with administrator rights and then type cscript.exe ScriptName (including the full path with parameters, if any).


 


To reset the period that unused objects remain in the cache

1.         From the Start menu, click Run, type regedit.exe, and then click OK.

2.        In the registry editor, navigate to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters

3.        Right-click the Parameters subkey, point to New, and then click DWORD Value.

4.        In the New Value box, type ObjectCacheTTL

5.        Right-click ObjectCacheTTL, and then click Modify.

6.        Under Base, click Decimal.

7.        In the Value Data box, type the number of seconds that you want an unused object to remain in the cache, and then click OK.

The default value is 30 (seconds). You can enter any value from zero, to disable caching, through 4,294,967,295 (unlimited), to disable the object-cache scavenger and allow cached objects to remain in the cache until the cached object changes.

Change the Balance of the File System Cache to the IIS 6.0 Working Set

By default, servers running Windows Server 2003 are configured to give preference to the file system cache over the working sets of processes when allocating memory (through the server property Maximize data throughput for file sharing). Although IIS 6.0–based servers benefit from a large file system cache, giving the file system cache preference often causes the IIS 6.0 pageable code to be written to disk, which results in lengthy processing delays. To avoid these processing delays, set server properties to maximize data throughput for network applications.


To maximize data throughput on the server for network applications

1.         In Control Panel, double-click Network Connections, right-click Local Area Connection, and then click Properties.

2.        Select File and Printer Sharing for Microsoft Networks, and then click Properties.

3.        Under Optimization, select Maximize data throughput for network applications.

Limit Connections

If your server does not have enough memory, limiting the number of connections on the server might help alleviate the shortage because some physical memory (about 10 KB per connection) is consumed by the data structures that the system uses to keep track of connections. For more information about limiting connections to save memory, see "Limiting Connections to Manage Resourcesiisrg_per_ISHV" earlier in this chapter.

Limit the Queue Length for Application Pools

If you are running your server in worker process isolation mode, you can limit application pool queue lengths to prevent large numbers of requests from queuing up and overloading your server. When the queue length limits feature is enabled (it is enabled by default), IIS monitors the number of requests in a designated application pool queue before queuing a new request. Use IIS Manager to change the default limit of 1,000 requests for application pool request queues.

If adding a new request to the queue exceeds the maximum queue length, the server rejects the request and sends a 503 error (Server Too Busy) to the client. However, requests that are already queued remain queued even if the limit is changed to a value that is less than the current queue length.

Use the following procedure to set a limit on the queue length for an application pool.


Important

You must be a member of the Administrators group on the local computer to perform the following procedure or procedures, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run IIS Manager as an administrator. At a command prompt, type runas /User:Administrative_AccountName "mmc %systemroot%\system32\inetsrv\iis.msc".


 


To change an application pool's queue length limit

1.         In IIS Manager, expand the local computer, expand the Application Pools folder, right-click the application, and then click Properties.

2.        On the Performance tab, under Request queue limit, select the Limit the kernel request queue to check box.

3.        In the requests box, type or select the maximum number of queued requests to allow. The default limit is 1,000 requests.


Important

If you clear the Limit the kernel request queue to check box, IIS does not apply a request limit. Without a limit, IIS might queue requests until your server runs out of memory.


4.        Click Apply, and then click OK.

For information about configuring application pool queue length limits by using metabase properties, see the AppPoolQueueLength property in the "Metabase Property Reference" in IIS 6.0 Help.

Adjust Resource Allocation in Windows

System processing is managed by Windows Server 2003, which can allocate processor and memory resources among tasks. If your server needs a temporary performance boost, you can temporarily adjust resource allocation in Windows to allocate the resources where you need them:

u        To obtain a faster response time, you can set Windows to allocate more processor time to the program that you are currently running.

u        If you want to run background programs, such as printing or disk backup, while you work, you can have Windows share processor resources equally between background and foreground programs.

For more information about changing the way that Windows allocates processor resources, see "Change the performance of foreground and background programs" in Help and Support Center for Windows Server 2003.

Limit Performance Logging

Always keep in mind that performance logging uses system resources. When you are not actively checking performance, disable performance-related logging to squeeze a bit more performance from your server.

Servers running IIS 6.0 rely on the speed and efficiency of their processors. IIS 6.0 code is multithreaded for efficient scaling on uniprocessor and multiprocessor computers, and is largely self-tuning. Even so, processor bottlenecks can occur on very active servers.

A processor bottleneck occurs when one or more processes consume the majority of the processor time. This forces threads that are ready to be executed to wait in a queue for processor time. Processor bottlenecks can occur on multiprocessor computers even when only a single processor is fully loaded, if the work in the queue cannot be — or is not — distributed to the other processors. Because a processor bottleneck is not centered in other components, such as memory, disks, or network connections, upgrading or adding to those components does not fix this performance problem, and can sometimes make it worse.

The processors on a server running IIS 6.0 must support the operating system and processes unrelated to Internet services, in addition to IIS 6.0 processes. The processors must also support applications related to Internet services, such as those that assemble data from Microsoft® SQL Server databases or generate dynamic Web pages.

To identify processor bottlenecks on the server, you need to monitor process activity, connections, and threads. After evaluating the data, determine the appropriate measures for improving processor performance through hardware upgrades, software configuration changes (limiting connections or allowing a higher thread count), or the redesigning of Web sites to reduce the processor workload.

The relationships among threads, connections, and requests are complex, especially in IIS 6.0, which uses the worker thread model rather than the simpler, and less efficient, thread-per-client model. Because of the complexity of the model, it is important to obtain a baseline from which to evaluate your system if a bottleneck occurs.

To identify performance bottlenecks, perform the following types of monitoring activity:

u        Monitor processor activity by using performance counters and other tools.

u        Monitor connections to determine how your server responds to managing different numbers of connections.

u        Monitor threads, including context switches, interrupts, and deferred procedure calls.

Several tools are available for monitoring processor performance:

u        Use the Web Capacity Analysis Tool (WCAT) to perform stress tests. For information about using WCAT, see "Using WCAT as a Stress Clientiisrg_per_YPGT" later in this chapter.

u        To monitor process performance on servers running Windows Server 2003, you can use Task Manager, System Monitor, and Performance Logs and Alerts.

Remember that all monitoring tools use system resources. Monitor the processor use of the process in which the tool runs; then, before you analyze your data, subtract the processor time of the tool process from the data.

To collect data about processor activity, monitor the counters that are listed in Table 6.19. The % Processor Time counter is the primary indicator of processor activity, displaying the average percentage of busy time observed during the sample interval.

Table 6.19   Counters for Monitoring Processor Activity

Object\Counter

Value

System\Processor Queue Length

The number of threads in the processor queue. Shows ready threads only, not threads that are running. Even multiprocessor computers have a single queue for processor time; thus, for multiprocessors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than two threads per processor is normally acceptable, depending upon the workload.

System\Context Switches/sec

The combined rate at which all processors on the computer are switched from one thread to another.

Processor (_Total)\% Processor Time

The average percentage of time that all processors are active. This counter is the primary indicator of average processor activity. This value is derived by calculating the percentage of time during the sample interval that all processors spent in executing their idle thread (which consumes cycles on a processor when no other threads are ready to run), and then subtracting the result from 100 percent.

Processor\% Processor Time

The average percentage of processor use for each processor (#0, #1, and so on).

Processor\% Privileged Time

The average percentage of processor time that is spent in privileged mode. In Windows Server 2003, only privileged mode code has direct access to hardware and memory. Application threads can be switched to privileged mode to run operating system services.

Processor\% User Time

The average percentage of processor time that is spent in user mode. User mode is a restricted processing mode designed for applications, environment subsystems, and integral subsystems. The alternative, privileged mode, is designed for operating system components, allowing direct access to hardware and memory. The operating system switches application threads to privileged mode to access operating system services.

Process\% Processor Time

The average percentage of processor use attributable to each processor, either for a particular process or for the total for all processes (shown in the list of instances).

 


Tip

A memory bottleneck can sometimes look like a processor or disk bottleneck. If the system does not have enough physical memory to store the code and data that are needed, the processor spends substantial time paging. Before adding or upgrading processors or disks, you need to monitor the memory on your server. For more information about monitoring memory, see "Monitoring Overall Server Memoryiisrg_per_QLKV" earlier in this chapter.


Analyzing Processor Activity Data

Of the counters listed in Table 6.19, the System\Processor Queue Length counter is probably the most important for analyzing processor activity data. This counter displays the number of threads waiting to be processed in the single queue shared by all processors. Sustained high rates of processor activity, which leave little excess capacity to handle peak loads, are often associated with processor bottlenecks. Processor activity itself only indicates that the resource is being used, not that maximum use of the resource is a problem. However, a long, sustained queue indicates that threads are being kept waiting because a processor cannot handle the load assigned to it.

A sustained processor queue length of two or more threads (as indicated by the System\Processor Queue Length counter) typically indicates a processor bottleneck. You can set an alert in Performance Logs and Alerts to notify administrators when the processor queue length is unacceptably high.

The Processor\% Processor Time counter is most often used as a general measure of processor activity on both uniprocessor and multiprocessor computers. On a multiprocessor server, use this counter to reveal unequal distribution of processor load. You might have a processor bottleneck if % Processor Time numbers are high while usage of the network adapter and disk I/O remain well below capacity.

On multiprocessor computers, use the total instance of the Processor\% Processor Time counter — for example, Processor(_Total)\% Processor Time — to monitor system-wide processor use. For multiprocessor use, this counter represents the active time of all processors divided by the number of processors. If the server workload is shared equally among all processors, the total instance time is an excellent measure of processor activity.

Windows Server 2003 is designed for efficient scaling and includes several strategies for balancing processor load. An application, however, can create an imbalance by setting a processor affinity, which binds a process to a single processor. To identify processor bottlenecks related to processor affinity, chart Processor\% Processor Time for each processor on the computer.


Note

Though processor affinity can overload a single processor, it can improve performance by reducing the number of processor cache flushes as threads move from one processor to another. You will need to assess, through monitoring, whether the trade‑off is acceptable. For information about assigning processor affinity to an application pool or Web garden, see "Improving Processor Performanceiisrg_per_XLAJ" later in this chapter.


Optimizing Processor Activity

If data shows a large processor queue with all processors busy, view a histogram of Process\% Processor Time for each process. To do this, click the View Histogram button on the toolbar in System Monitor. The histogram shows the processor time consumed by each process.

Based on the histogram readings, consider making the following adjustments to optimize performance:

u        If a single bar in the histogram rises above all of the others, the process represented by the bar might be consuming a disproportionate share of processor time and causing a bottleneck. Consider replacing the application running in that process, or moving the process to another server.

u        If the processors are being shared equally by several processes, consider upgrading or adding processors. (Multithreaded processes benefit most from additional processors.)

For more information about processor use by applications related to IIS, see "Improving Application Performanceiisrg_per_CREJ" later in this chapter.

It is important to determine how your server responds when it is managing different numbers of connections. After collecting data on connection trends, you can associate data about general server performance with the number of connections being served.

Each connection that an IIS 6.0 service establishes consumes processor time. The network adapter interrupts the processor to signal that a client has requested a connection. Further processing is required to establish and maintain the connection, to fulfill client requests sent over the connection, and — when the connection is closed — to delete the structures that serviced the connection. Each time a connection is established, the load on the server increases.

IIS 6.0 includes several features to optimize its handling of connections. For example, the HTTP Keep-Alives feature, which is enabled by default, maintains an open connection between the server and browser across multiple requests until an entire Web page is downloaded. This feature significantly improves bandwidth performance on most servers and improves response times for clients. For more information about HTTP Keep-Alives, see "Enabling HTTP Keep-Alives to Keep Connections Openiisrg_per_ZFOO" earlier in this chapter.

You can use IIS 6.0 logging to monitor the number of connections that your server makes and to track patterns of client demand for your server. Table 6.20 lists the counters that you can use with Performance Logs and Alerts to monitor connections to IIS 6.0.

Table 6.20   Performance Counters for IIS 6.0 Service Connections

Object\Counter

Value

Web Service\Current Connections
FTP Service\Current Connections

The number of connections maintained by the service during the most recent sample interval.

Web Service\Maximum Connections
FTP Service\Maximum Connections

The maximum level of simultaneous connections since the server started up.

 

Because these counters display the last observed value, and not an average, you must log their values over time to get a reliable sample. These counters can exaggerate the number of simultaneous connections because, at any given moment, some entries may not have been deleted even though the connections on which they are based have been closed.

For more information about configuring and interpreting IIS 6.0 logs, see "Analyzing Log Filesiisrg_log_GADT" in this book.

Analyzing Connection Data

Identify patterns of client demand for your server by monitoring the number of connections. Log connection data at regular time intervals, and look at the number of connections served during each interval. Observe the size of the processor queue and the usage on each processor during periods of small, moderate, and large numbers of connections. This data shows how your configuration responds to each load level.

You can identify a processor bottleneck during a given time interval by observing one of the following:

u        A long, sustained processor queue (with more than two threads).

u        High usage rates on one or more processors.

u        A curve in the graph of the Current Connections counter on any IIS 6.0 service performance object that reaches a high value and then plateaus. This pattern often indicates that additional connections are being blocked or rejected.

The Active Server Pages, Web Service, FTP Service, and SMTP Server counters collect data at the OSI application layer. If any connections are blocked, rejected, or reset between the transport and application layers, counts of TCP/IP connections might not equal the sum of HTTP, FTP, and SMTP connections. For information about monitoring connections at lower layers, see "Monitoring Network Activityiisrg_per_OMPW" earlier in this chapter.

Optimizing Connections

To prevent processor bottlenecks, make certain that a lengthy processor queue is not forming when you serve large numbers of connections. You can usually avoid a bottleneck during peak usage by setting the connection limit to twice the average value of the Current Connections counter.

If the processor regularly develops a bottleneck when servicing large numbers of connections, consider upgrading or adding processors, or limit the maximum number of connections on the server. Limiting connections can cause the server to block or reject connections, but it helps to ensure that accepted connections are processed promptly.

For information about limiting connections, including how to configure this setting, see "Limiting Connections to Manage Resourcesiisrg_per_ISHV" earlier in this chapter.

IIS 6.0 runs in a set of multithreaded processes designed for efficient scaling on uniprocessor and multiprocessor systems. Threads are the sequences of execution in each process that run the process code on the processor. In the IIS 6.0 process, there is no simple association between threads and connections or between threads and requests, nor is there an easily quantifiable relationship between the optimum number of threads in the process and the number of files served, the number of requests filled, or the number of connections maintained.

Because IIS 6.0 uses the worker thread model (rather than the simpler, thread-per-client model, which dedicates a thread to each connection or request), a pool of threads, known as the worker threads, is dedicated to accepting and monitoring all connections. This frees other threads to do the remaining work of the application, such as authenticating users; parsing client requests; locating, opening, and transmitting files; and managing internal data structures.

Even though you cannot associate individual threads with connections or requests, you can:

u        Count the number of threads in the IIS 6.0 process.

u        Measure the amount of processor time that each thread gets.

u        Associate the number of threads (and processor activity) with the number of current connections, number of files served, and other measures of server activity and performance.

Several tools — including Performance Logs and Alerts, Task Manager, and System Monitor — monitor or enumerate the threads in a process. Individual threads are difficult to monitor, especially if they frequently start and stop. Monitoring threads is also costly. Be sure to monitor the overhead of the process in which your tool runs (by monitoring the Process\% Processor Time counter), and subtract this from the overall processor time for the data that you collect.

Monitoring Threads and Context Switches

Table 6.21 lists the counters that monitor threads and context switches. You can add to this list any counters that you use to associate numbers of threads with performance, such as Web Service\Current Connections, Web Service\Bytes/sec, or Server\Logon/sec.

Table 6.21   Counters for Monitoring IIS 6.0 Threads

Object\Counter

Value

Process (W3wp1)\Thread Count

The number of threads created by the process. This counter does not indicate which threads are busy and which are idle. It displays the last observed value, not an average.

Thread (W3wp1:Thread #)\% Processor Time

The percentage of processor time that each thread of the worker process is using.

Thread (W3wp1/Thread #)\Context Switches/sec

The rate of switches from one thread to another. Thread switches can occur either inside of a single process or across processes.

System\Context Switches/sec

The combined rate at which all processors on the computer are switched from one thread to another.

1 Monitor the W3wp instance if you are running your Web server in worker process isolation mode. If you are running your server in IIS 5.0 isolation mode, monitor either the Inetinfo instance (for in-process applications) or the Dllhost instance (for out-of-process applications).

 

Balancing threads against overall performance as measured by connections and requests can be difficult. Any time that you tune threads, follow up with overall performance monitoring to see whether performance increases or decreases.

You can chart the Process\Thread Count: W3wp value over time to see how many threads the worker process creates and how the number of threads varies. Then, observe the processor time for each thread in the process (Thread\% Processor Time: W3wp/Thread #) during periods of high, medium, and low server activity (as indicated by the other performance measures).

To determine if you need to adjust the thread count, compare the number of threads and the processor time for each thread in the process to the total processor time. If the threads are constantly busy, but are not fully using the processor time, you might improve performance by allowing more threads. However, if all the threads are busy and the processors are operating at close to their maximum capacity, it is best to distribute the load across more servers instead of increasing the number of threads.

Context switch counters are provided for the System and Thread objects. If you decide to increase the maximum size of any of the thread pools, it is important to monitor the counters for context switches. Context switches occur when a running thread voluntarily relinquishes the processor, is preempted by a higher priority ready thread, or switches between user mode and kernel mode to use an Executive or subsystem service. Switching to the subsystem process causes one context switch in the application thread; switching back causes another context switch in the subsystem thread.

Increasing the number of threads can increase the number of context switches to the point that performance decreases rather than increases. Ten thousand or more context switches per second is high. If you see numbers in that range, consider reducing the maximum thread pool size.

You should also observe the patterns of context switches over time, which indicate that the kernel has switched the processor from one thread to another. A large number of threads is likely to increase the number of context switches. Although they allow multiple threads to share the processor, context switches also interrupt the processor and might interfere with its performance, especially on multiprocessor computers.

Controlling processor affinity can improve performance by reducing the number of processor cache flushes as threads move from one processor to another. For example, you might be able to reduce cache flushes for dedicated servers by assigning processor affinity. However be aware that dedicating a program to a particular processor might prevent other program threads from migrating to the least-busy processor.

Monitoring Interrupts and Deferred Procedure Calls

You also need to monitor the counters for interrupts and deferred procedure calls (DPCs). Table 6.22 lists the counters to use.

Table 6.22   Counters to Monitor Interrupts and Deferred Procedure Calls

Object\Counter

Value

Processor\Interrupts/sec

The rate, in average number of interrupts in incidents per second, at which the processor received and serviced hardware interrupts. It does not include deferred procedure calls, which are counted separately.

Processor\% DPC Time

The percentage of time that the processor spent receiving and servicing deferred procedure calls during the sample interval. Deferred procedure calls are interrupts that run at a lower priority than standard interrupts.

 

The value of the Processor\Interrupts/sec counter is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network adapters, and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention, suspending normal thread execution. The system clock typically interrupts the processor every 10 milliseconds, creating a background of interrupt activity.

Use the Processor\Interrupts/sec and Processor\% DPC Time counters to determine how much time the processor is spending on interrupts and deferred procedure calls. These two factors can be another source of load on the processor. Client requests can be a major cause of interrupts and deferred procedure calls. Some new network adapters include interrupt moderation, which accumulates interrupts in a buffer when the level of interrupts becomes too high.

Optimizing Thread Values

By default, the IIS 6.0 process creates as many as four threads per processor. IIS 6.0 continually adjusts the number of threads in its process in response to server activity. For most systems, this tuning is sufficient to maintain the optimum number of threads, but you can change the maximum number of threads per processor if your system requires this. If the threads in the IIS 6.0 process appear to be overworked or underutilized, consider these tuning strategies:

u        If nearly all of the threads of the IIS 6.0 process are busy nearly all of the time, and the processors are at or near their maximum capacity, consider distributing the workload among more servers. You can also add processors.

u        If nearly all threads appear busy, but the processors are not always active, consider increasing the maximum number of threads per processor. Do not increase the maximum number of threads unless you have processors with excess capacity. More threads on the same number of processors cause more interrupts and context switches, and result in less processor time per thread.

To adjust the maximum number of threads in the IIS 6.0 service process, use a registry editor to add the MaxPoolThreads entry to the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters


Caution

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the <A HREF="http://go.microsoft.com/fwlink/?LinkID=4543" TARGET="_blank">Registry Reference</A> on the Windows Server 2003 Resource Kit companion CD or on the Web at http://www.microsoft.com/reskit.


The MaxPoolThreads entry is calculated in units of threads per processor. Do not set this value below 2 or above 20. You can try setting the MaxPoolThreads entry to a higher value if back-end latency is higher; set the entry to a lower value for applications that are CPU-intensive. Continue monitoring the system carefully to make sure that changing the number of threads allowed achieves the effect that you want.

If your data on processor performance indicates that processor queues are developing regularly or while a server is handling large numbers of connections, start by monitoring the server's memory. Rule out a memory bottleneck or add more memory before (or in addition to) adding or upgrading processors.

In addition to the methods for optimizing thread values (discussed earlier in "Monitoring Threadsiisrg_per_SRFQ"), consider making the following adjustments.

Upgrade the L2 cache

When adding or upgrading processors, choose processors with a large secondary (L2) cache. Server applications, such as IIS, benefit from a large processor cache because their instruction paths involve many different components. A large processor cache (2 MB or more if external, up to the maximum available if on the CPU chip) is recommended to improve performance on active servers running IIS 6.0.

Add network adapters

If you are administering a multiprocessor system that does not distribute interrupts symmetrically, you can improve the distribution of the processor workload by adding network adapters so that there is one adapter for every processor. Generally, you only add adapters when you need to improve the throughput of your system. Network adapters, like any additional hardware, have some intrinsic overhead. However, if one of the processors is nearly always active (that is, if Processor\% Processor Time = 100) and more than half of its time is spent servicing deferred procedure calls (if Processor\% DPC Time > 50), then adding an adapter is likely to improve system performance, as long as the available network bandwidth is not already saturated.

Upgrade network adapters

If you are adding or upgrading network adapters, choose those with drivers that support interrupt moderation cards, which can perform transfers in the background without processor help. Interrupt moderation prevents the processor from being overwhelmed by bursts of interrupts. Consult the driver manufacturer for details. Also, if at all possible, use adapters that support TCP checksum offloading.

Upgrade to a multiprocessor computer

A server-application environment, such as e‑commerce sites running COM+ applications, is much more processor-intensive than a typical file or print server environment because much more processing is taking place at the server. For that reason, high-end multiprocessor computers can increase performance in server-application environments. IIS 6.0 introduces a new kernel-mode driver for HTTP parsing and caching that is tuned to increase Web server throughput and scalability of multiprocessor computers.

Assign processor affinity to better use CPU caching

To efficiently use CPU caches on multiprocessor servers, you can configure application pools to establish affinity between worker processes and the processors. Processor affinity forces worker processes to run on a specific microprocessor or CPU, and applies to all worker processes serving a particular application pool. You can also use processor affinity with Web gardens that run on multiprocessor computers where clusters of CPUs are dedicated to specific application pools.

Controlling processor affinity can improve performance by reducing the number of processor cache flushes as threads move from one processor to another. For example, you might be able to reduce cache flushes for dedicated servers by assigning processor affinity. However, the performance trade‑off is that dedicating a program to a particular processor might prevent other program threads from migrating to the least-busy processor.

If you want to assign a particular process or program to a single processor to improve its performance — possibly at the expense of other processes — configure the SMPAffinitized and SMPProcessorAffinityMask metabase properties. For more information about assigning processor affinity, including how to configure these metabase properties, see "Running IIS 6.0 as an Application Serveriisrg_was_OVERVIEW" in this book.

Limit connections

If you cannot upgrade or add processors, consider reducing the maximum number of connections that each IIS 6.0 service accepts. Limiting connections can result in connections being blocked or rejected, but it helps ensure that accepted connections are processed promptly.

Adjust the maximum number of threads

IIS 6.0 tunes the number of threads in its process dynamically. The dynamic values are usually optimal; in extreme cases of very active or underused processors, however, it might help to adjust the maximum number of threads. If you change the maximum number of threads, continue careful testing to make sure that the change has improved performance. The difference is usually quite subtle.

Redesign the Web site

You can improve performance and reduce the processor workload by optimizing database use, calling compiled components from scripts in ASP pages, using Internet Server API (ISAPI) instead of ASP (and ASP or ISAPI instead of CGI applications), and eliminating large bitmapped images or optimizing them to reduce file size. For more information about optimizing Web site performance, see "Improving Application Performanceiisrg_per_CREJ" later in this chapter.

Web applications continue to increase in popularity, constituting an ever larger proportion of the average Web server file base. The challenge for administrators is to preserve speed and efficiency while serving complex applications. By monitoring and tuning different types of applications, in addition to static HTML pages, you can estimate application overhead during periods of varying activity to ensure that your server is prepared for the workload.

Use the tools and counters that are included with IIS 6.0, such as those discussed here, to help you optimize application performance:

u        Test applications with stress tools. Use a stress client like the Web Capacity Analysis Tool (WCAT) to test your applications under a variety of workloads.

u        Monitor and tune applications. When you enable ASP.NET and ASP pages on a Web server, IIS provides application-specific counters for monitoring and tuning their performance.

If Web applications are an important part of your site, the performance of those applications is critical in determining the capacity of the site. In turn, testing is the only way to find out the capacity and performance of a Web application.

If you are unfamiliar with stress testing or need a refresher, look at the following sections:

u        Measuring performance by using a stress client. Provides an introduction to performing stress testing.

u        Using WCAT as a stress client. Details how to obtain the WCAT tool and its documentation. WCAT is a stress client provided in the IIS 6.0 Resource Kit Tools.

u        Estimating baseline performance for applications. Compares the relative performance capabilities of specific application types to help you proactively develop applications that provide optimal performance.

Use a stress client to test different server and network configurations under a variety of workloads. For example, use a stress client to test how your server responds to different workloads or to test the same workload with varying configurations of the server. Some stress clients include prepared test workloads; optionally, you can create your own workloads.

A stress client simulates clients and servers communicating over a network, and usually requires at least four primary subsystems:

u        At least one computer that simulates a client, which runs one or more virtual clients.

u        One computer that acts as a server.

u        One computer, called a controller, that initiates and monitors the test.

u        A network.

Both the client and controller components can run on one computer. (You can also run the server component on the same computer, but doing so might provide inaccurate results.)

To produce a more realistic test of your server, link it to client computers that are powerful enough to drive the server. The processors in the client computers must be fast enough to prevent a client bottleneck when accessing the server computer. If the client processors are slower than the server, you might need to link more client computers to each server.

Stress clients usually work best if the network that connects the computers has little or no traffic that is unrelated to the test. If possible, use a link dedicated only to the test, and run the tests on a 100 megabits per second — or faster — network.

Test different performance features to observe the effect they have on your server. To test a feature, first run a stress client test with the feature, then run the same test without it. Be sure to run the "with feature" and "without feature" versions of the test on varying workloads and multiple clients. For example, use a stress client to test the following features:

u        Set different connection limits, such as HTTP Keep-Alives and connection timeouts.

u        Test several compression combinations. For example, compress only static files, only dynamic files, or both. Compress at different compression levels for both file types. Also, check to see that the correct set of compressible file types is included in your compression configuration.

u        Test bandwidth throttling at different times and on different services.

u        Test different hardware combinations, including multiprocessor machines with and without processor affinity.

u        Compare the benefits of running different health-monitoring features, such as rapid-fail protection and worker process recycling.

u        Test security-related features, such as SSL.

Repeat each test several times, and average the results to eliminate the effects of unintended variations in the test conditions. Then compare the results of the "with feature" and "without feature" tests. Consistent differences in the results of the tests are likely to indicate the overhead associated with the feature. You can use these results for planning configuration changes.

The Internet Information Services (IIS) 6.0 Resource Kit companion CD includes a stress client called the Web Capacity Analysis Tool (WCAT), which is a script-driven command-line tool. WCAT includes a stress client tool (Wcclient.exe) to simulate the clients and a controller tool (Wcctl.exe) to initiate and monitor the testing.

You can install the Resource Kit Tools by running IIS60rkt.exe from the companion CD. When you perform a default installation of the Resource Kit Tools, the WCAT client and controller files are installed in the LocalDrive:\Program Files\IIS Resources folder.

A WCAT test begins with the controller locating and interpreting input files. A controller input file includes three required sections (Configuration, Script, and Distribution) and one optional section (Performance, for specifying which performance counters to monitor). The controller uses the input files to send instructions to the clients, including which tests to run. WCAT includes a prepared input file (Sample.ubr, in the LocalDrive:\Program Files\IIS Resources\WCAT Controller\Scenarios folder) that contains a test for stressing the default IIS Web page.

When a WCAT test is complete, the controller collects the test results and writes them to output files. Output files include a log file, which you can optionally configure as an XML-formatted file, and an optional performance results file, which contains data collected from performance counters on the server.

If you specify performance counters in the Performance section of the .ubr file, WCAT logs the counter data in its usual report but also produces a performance log file in a tab-separated format, so that you can import the logged counter data into a spreadsheet or data-processing application. The log of performance data that WCAT generates is stored, by default, in the WCAT Controller\Scenarios folder. You can open this log, which is a text file, by using any word processor.

For more information about obtaining and using WCAT, see Internet Information Services (IIS) 6.0 Resource Kit Tools Help (IISTools.chm), which is located in the folder where you install the tools.

Before you develop a new application, it is useful to understand the performance capabilities of different types of Web applications. Table 6.23 provides a guide to the relative performance of different types of applications, where n represents the fastest application, and all other application types are rated relative to its performance.

Table 6.23   Relative Performance of Different Application Types

Application Type

Relative Cost

Comments

Static page (kernel mode)

n

Fastest and simplest Web page.

Static page (user mode)

2n

 

ISAPI

2n

Relative speed for a simple ISAPI application.

ASP.NET

5n

Relative speed for a simple ASP.NET application.

ASP

10n

Relative speed for a simple ASP application.

CGI

100n

Slowest.

 

Microsoft® Visual Studio® .NET provides Application Center Test (ACT) to help you test and monitor the performance of your Web application. ACT simulates a large group of users by opening multiple connections to a Web server and rapidly sending HTTP requests. ACT is designed to stress-test Web servers and to analyze performance and scalability problems with Web applications. For more information about ACT, see the MSDN Library link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources. On the MSDN Library Web page, search for "ACT."

For more information about Web application development, including ASP.NET and ASP applications, see the "Web Application Guide" in IIS 6.0 Help.

To ensure that all of your Web applications run reliably and efficiently during peak hours as well as normal usage periods, you should monitor and tune your applications, obtaining baseline data to compare the performance of different types of applications. If you uncover applications or groups of applications that appear to run inefficiently, review the suggestions for improving application performance in "Optimizing Application Design and Administrationiisrg_per_JOLY" later in this chapter.

You can also improve application performance by using the connection timeout and HTTP compression features that IIS provides. Certain applications, such as ASP pages, provide metabase properties for customizing these features. For more information about using these features to improve application performance, see "Administering Network Resourcesiisrg_per_QURK" earlier in this chapter.

When you make changes to your applications or to the hardware on which your applications run, be sure to test the changes in a nonproduction environment before implementing them on production servers.

IIS provides application-specific counters that you can monitor to obtain performance data about different types of applications that run on your servers.

u        Monitor applications that use the WWW service by observing counters that monitor ISAPI extensions, CGI requests, and so forth.

u        Monitor ASP pages, and tune metabase properties for ASP.

u        Monitor ASP.NET applications.

Monitor the counters in Table 6.24 to determine how the WWW service is processing ISAPI, CGI, POST, and GET requests.

Table 6.24   Counters That Provide Data About WWW Service Applications

Object\Counter

Value

Web Service\ISAPI Extension Requests/sec

Web Service\CGI Requests/sec 

The rates at which the server is processing ISAPI and CGI application requests. If these values decrease due to increasing loads, you might need to redesign the applications.

Note: ASP is an ISAPI extension; therefore ASP requests are included in the first counter.

Web Service\Get Requests/sec

Web Service\Post Requests/sec

The rate at which these two common HTTP request types are made to the server. POST requests are generally used for forms and are sent to ISAPIs (including ASP) or CGIs. GET requests make up almost all other requests from browsers and include requests for static files, ASPs and other ISAPIs, and CGI requests.

 

If you are running ASP pages on your server, the counters listed in Table 6.25 can help you determine how well the applications are performing. These counters provide the sum of the ASP performance counters for all processes hosting ASP; the data cannot be broken down by process. For information about monitoring the performance of your ASP.NET applications, see "Monitoring ASP.NET Performanceiisrg_per_WUGO" later in this chapter.

Table 6.25   Counters Used to Monitor ASP Performance

Object\Counter

Value

Active Server Pages\Requests/sec

The number of ASP responses during the past second. This counter excludes requests for static files or other dynamic content, and can fluctuate considerably based on the complexity of the ASP pages and the capacity of your Web server.

Active Server Pages\Requests Executing

The number of ASP requests currently executing (for example, the number of active worker threads).

Active Server Pages\Request Wait Time

The number of milliseconds that the most recent ASP request was waiting in the queue.

Active Server Pages\Request Execution Time

The number of milliseconds that the most recent ASP request took to execute. This value can be somewhat misleading because it is not an average.

Active Server Pages\Requests Queued

The number of queued ASP requests that are waiting to be processed. The maximum number for this counter is determined by the metabase property AspRequestQueueMax.

 

Analyzing the Data

The Active Server Pages\Requests/sec counter excludes requests for static files or other dynamic content, and can fluctuate considerably based on the complexity of the ASP pages and the capacity of your Web server. If this counter is low during spikes in traffic on your server, your applications might be causing a bottleneck.

It is difficult to give an ideal value for the Active Server Pages\Requests Executing counter. Some factors to consider include:

u        If pages execute quickly and do not wait for I/O (for example, loading a file or making a database query), the number of ASP requests that are currently executing is likely to be low — little more than the number of processors when the computer is busy.

u        If pages must wait for I/O, the number of pages executing is likely to be higher —up to the maximum thread count allowed for an ASP processor (set by the AspProcessorThreadMax metabase property) multiplied by the number of processors, multiplied by the number of processes hosting ASP. (The default AspProcessorThreadMax value is 25.)

u        If the Requests Executing counter value equals the value of the AspProcessorThreadMax property, if Requests Queued is large, and if CPU usage is low, you might need to increase the value of the AspProcessorThreadMax metabase property.


Important

The value of the AspProcessorThreadMax metabase property can significantly influence the scalability of your Web applications and the performance of your server. Before changing the setting, be sure to read about this property and its use in IIS 6.0 Help.


 

The Request Execution Time counter can be misleading because it is not an average. For example, if you regularly receive 30 requests for a page that executes in 10 milliseconds (ms) to every one request for a page that executes in 500 ms, the counter is likely to indicate 10 ms even though the average execution time is over 25 ms.

Ideally, the Requests Queued and Request Wait Time counters remain close to zero; however, they can vary under varying loads (depending on the application) while the server still provides good performance. If these numbers vary too much from their expected range, you might need to rewrite your ASP applications. If the queue size and wait time increase, or if the queue limit is reached, browsers display the message "HTTP 500/Server Too Busy."

For more information about ASP performance counters, including additional ASP counters, see "IIS 6.0 Performance Countersiisrg_cou_EWGJ" in this book.

If your Web server is running ASP applications, you can help optimize server performance by tuning the metabase properties described in this section. You can retrieve and change these properties by using WMI or ADSI, or by directly editing the metabase with a text editor. Changes to most of these properties do not take effect until you restart the WWW service.

For more information about the default values of these metabase properties, see "Metabase Property Reference" in IIS 6.0 Help.

AppAllowDebugging

The AppAllowDebugging metabase property specifies whether ASP debugging is enabled on the server. When this property is enabled, IIS application threads are serialized; only one thread can execute for each application at one time. Serialized threads adversely affect Web server performance. You should retain the default setting for this property, which is false, on all production servers. Set this property to true only on a test server when you are debugging an application during its deployment phase.

AspBufferingOn

The AspBufferingOn metabase property turns on buffering in ASP, so that all output from an application is collected in the ASP output buffer before the buffer is flushed to the client browser (default behavior). If this property is set to false, output from ASP scripts is written to the client browser as the client browser becomes available. Set this property to true on all production Web servers.

AspProcessorThreadMax

The AspProcessorThreadMax metabase property specifies the maximum number of worker threads per processor that IIS can create. To find out the maximum number of worker threads that IIS allows per ASP process, multiply this value by the number of processors on your server. If you decrease this value, monitor performance to make sure that the lower thread limit does not degrade performance. If it does, increase the value again.

AspQueueConnectionTestTime

The AspQueueConnectionTestTime metabase property specifies the maximum time, in seconds, that a request remains queued before ASP checks to determine whether a client is still connected. If a request is in the queue longer than the queue connection test time, the server checks whether the client is still connected before beginning execution.

This feature can help you handle impatient users who fill up the request queue with numerous attempts at the same page. Often, users do not wait more than a few seconds for ASP pages to process. Although the maximum waiting time varies from user to user, the generally accepted maximum is about 10 seconds; so set a small value — for example, 3 seconds.

This property is useful for making ASP processing efficient only up to the point at which ASP begins to process the script. After the script is running, your application should continue to check for client connection at appropriate times, by using the IsClientConnected method of the ASP built‑in Response object. For long-running pages, make cautious use of Response.Flush to ensure that users perceive that the page is still alive and doing productive work. For more information about using this property, see the AspQueueConnectionTestTime property in the "Metabase Property Reference" in IIS 6.0 Help.

AspRequestQueueMax

The AspRequestQueueMax metabase property specifies the maximum number of ASP requests that are permitted in a queue. The default value is 3,000, but the optimal setting depends on the behavior of the application. If the execution time of the request is very short and the time in the queue is short, it is reasonable to decrease this value.

AspScriptEngineCacheMax

The AspScriptEngineCacheMax metabase property specifies the maximum number of scripting engines that ASP pages keep cached in memory (excludes currently running script engines). The default value is 250. Adjust the value according to the type of content in the application. If you are serving thousands of unique pages, server performance might improve if you increase the cache size so that the most frequently requested pages are accessed easily. A hit in the script engine cache means that you can avoid recompiling the template into byte code.

AspScriptFileCacheSize

The AspScriptFileCacheSize metabase property specifies the number of precompiled script files that can be stored in the ASP template cache. If you set the property to 4,294,967,295 (unlimited), all requested script files are cached. The default value is 500. Increase the value if you have many ASP pages. Do not set the value of this property to zero, which turns off all ASP caching and can severely impair your server's performance.

AspDiskTemplateCacheDirectory

The AspDiskTemplateCacheDirectory metabase property specifies the name of the directory where ASP stores compiled ASP templates to disk when the in-memory cache overflows. If you change the default directory, you must ensure that the identity of the processes running Asp.dll is assigned Full Control permission to the new directory. Typically, the identity of the worker processes running Asp.dll is the LocalSystem or Network Service account. You must specify a local path; ASP template caching fails if this property is set to a Universal Naming Convention (UNC) or mapped network path.

AspSessionTimeout and AspSessionMax

The metabase property AspSessionTimeout specifies, in minutes, the default amount of time that a session object is maintained after the last request associated with the object is received. AspSessionMax specifies the maximum number of concurrent sessions that IIS permits. For applications that take advantage of sessions, you might want to decrease the session timeout in order to reduce server overhead. If decreasing the session timeout causes the number of concurrent sessions to increase too much, you might need to set a lower session maximum.

AspTrackThreadingModel

The AspTrackThreadingModel metabase property specifies whether IIS checks the threading model of any components that your application creates. ASP no longer uses this metabase property, although it is still in the metabase to provide compatibility with existing administrative scripts. It is recommended that you retain this property's default value, which is false, to avoid the overhead incurred by the ASP track threading model and to help improve performance of your ASP application.

CacheISAPI

The CacheISAPI metabase property indicates whether ISAPI extensions are cached in memory after first use. If the value of this property is true (the default setting), ISAPI extensions, after they are loaded, remain in the cache until the server is stopped. If the value is false, extensions are unloaded from memory after the ISAPI extension is no longer in use.

ISAPI extensions are cached or not cached based on the value of this property when they are loaded into memory. Thus, if this property is changed after an extension is loaded and cached, the change has no effect on that extension until the Web server is restarted.

Although you might temporarily set this property to false to help with debugging, you need to keep this value set to true on all production Web servers. Because the ASP.dll is an ISAPI extension, disabling this property — which requires that every request be reloaded — degrades performance.

ASP.NET includes a number of performance counters that you can use to track the execution of your Web applications. When you do steady-state running analysis, you might want to ignore the first request and also any one-time initialization costs for objects. For example, when an ASP.NET page is requested for the first time, there is always the cost of compiling an instance of the Page class. After the initial cost is incurred, performance improves for subsequent requests.


Note

You can also use the built‑in ASP.NET tracing feature to track code execution for a page or an application.


Two performance objects are defined for ASP.NET, supporting two types of performance counters:

u        The ASP.NET performance object contains system counters that monitor events on the state server. These global counters are not bound to a particular application instance.

u        The ASP.NET Applications performance object contains application counters.

For example, there is a significant difference between the State Server Sessions counters for the ASP.NET performance object, which apply only to the computer on which the state server is running, and the Sessions counters for the ASP.NET Applications performance object, which apply only to user sessions that occur in process.

Unlike the ASP performance counters discussed earlier, which are exposed globally for the entire server computer, most of the ASP.NET performance counters are exposed per application.

Use System Monitor to view the counters for ASP.NET. If your Web server serves multiple applications, you need to specify a particular application instance when selecting a counter to monitor. In addition, System Monitor provides a __Total__ application instance, which aggregates the counter values for all applications on a server.

Useful Counters for Monitoring ASP.NET Applications

When monitoring the performance of your ASP.NET Web applications, try tracking the performance counters described in Table 6.26.

Table 6.26   ASP.NET Performance Counters

Object\Counter

Value

ASP.NET\Application Restarts

The aggregate number of restarts for all ASP.NET applications during the Web server's lifetime.

ASP.NET\Requests Queued

The number of ASP.NET requests waiting to be processed.

ASP.NET\Worker Process Restarts

The number of times that a worker process has restarted on the computer.

ASP.NET Applications\Errors Total

The total number of errors that have occurred in ASP.NET applications.

ASP.NET Applications\Requests/Sec

The number of requests executed per second for ASP.NET applications.

 

Application restarts, as reported by the ASP.NET\Application Restarts counter, are incremented with each Application_OnEnd event. An application restart can occur because changes were made to the Web.config file or to assemblies stored in the application's \Bin directory, or because too many changes occurred in Web Forms pages. A sudden increase in this counter can mean that your Web application is shutting down. If an unexpected increase occurs, be sure to investigate it promptly. This value is reset every time that IIS is restarted.


Note

The value of each ASP.NET performance counter is updated every 400 milliseconds.


Useful Counters for Troubleshooting ASP.NET Performance Problems

Table 6.27 describes some additional performance counters that you can use to troubleshoot performance problems with your Web applications.

Table 6.27   Performance Counters for Troubleshooting ASP.NET Applications

Object\Counter

Indicates

ASP.NET Applications\Pipeline Instance Count

The number of active pipeline instances.

.NET CLR Exceptions\# of Exceps Thrown

The total number of exceptions thrown since the start of the application. Collects data both on .NET exceptions and on unmanaged exceptions that are converted to .NET exceptions. For example, a null pointer reference exception in unmanaged code is rethrown in managed code as a .NET SystemNullReferenceException. Exceptions that are rethrown are recounted. This counter collects data from both handled and unhandled exceptions.

System\Context Switches/sec

The rate at which thread contexts are switched by all CPUs in the Web server. A high number usually indicates either high contention for locks or many switches between user and kernel mode by the thread. Be sure to investigate these problems by using sampling profiles and other tools.

 

Although exceptions occur infrequently, you might want to monitor the # of Exceps Thrown counter, because exceptions can have performance implications. Some code paths, however, rely on exceptions for their proper functioning. For example, the HttpResponse.Redirect method always throws an exception, ThreadAbortException. Therefore, it can be more useful to track the number of exceptions thrown by using the Errors Total counter to see if the exception generated an error for the application.

For more information about the ASP.NET performance counters discussed in this section, as well as other ASP.NET performance counters, see "IIS 6.0 Performance Countersiisrg_cou_EWGJ" in this book.

Balancing performance with concerns about the security of your Web applications can be an important issue, particularly if you run an e‑commerce Web site. Secure Web communications require more resources than do Web communications that are not secure, so you need to know when to use security techniques such as SSL certificates or any of the Windows authentication methods. Because SSL uses complex encryption, and encryption requires considerable processor resources, it takes much longer to retrieve and send data from SSL‑enabled directories. Therefore, you should place only those files that contain or receive sensitive information in your SSL‑enabled directory, keeping pages free of resource-consuming elements such as images.

If you use SSL, be aware that establishing the initial connection takes five times longer than reconnecting by using security information in the SSL session cache. The default time-out interval for the SSL session cache is 10 hours in Windows Server 2003. After secure data is deleted from the cache, the client and server must establish a new connection.

If you plan to support long SSL sessions, consider lengthening the SSL cache time-out interval by adding the ServerCacheTime entry to the registry. If you expect thousands of users to connect to your site by using SSL, estimate how long you expect SSL sessions to last, and then set the value of the ServerCacheTime entry to a number slightly higher than your estimate. Do not set the value much higher than your estimate, because the resulting time-out interval might cause your server to retain stale data in the cache.


Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the <A HREF="http://go.microsoft.com/fwlink/?LinkID=4543" TARGET="_blank">Registry Reference</A> on the Windows Server 2003 Resource Kit companion CD or on the Web at http://www.microsoft.com/reskit.


One reason for changing the default value for the SSL session cache is to force the client to authenticate more often. More frequent caching is sometimes useful, for example, if you know that the client is using a smart card and you want the Web page to be accessible only when the user inserts the smart card in the reader.

Before changing the SSL cache time-out interval, make sure that HTTP Keep-Alives are enabled (HTTP Keep-Alives are enabled by default). SSL sessions do not expire when you use them with HTTP Keep-Alives except when the browser closes the connection.


Important

You must be a member of the Administrators group on the local computer to run scripts and executables, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile /User:MyMachine\Administrator cmd to open a command window with administrator rights and then type cscript.exe ScriptName (including the full path with parameters, if any).


 


To configure the ServerCacheTime registry entry

1.         From the Start menu, click Run, type regedit.exe, and then click OK.

2.        In the registry editor, navigate to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
\SCHANNEL.

3.        Right-click the SCHANNEL subkey, point to New, and then click DWORD Value.

4.        In the New Value box, type the following: ServerCacheTime

5.        Right-click the ServerCacheTime entry and then click Modify.

6.        Under Base, click Decimal.

7.        In the Value Data box, type the value (in milliseconds) that you want to assign for the cache time (1 minute = 60,000 milliseconds), and then click OK. See Table 6.28 for commonly used cache times converted to milliseconds.

Table 6.28   Calculating ServerCacheTime Values for Secure Session Caching

Desired Cache Time (1 minute = 60,000 milliseconds)

ServerCacheTime Value (in Milliseconds)

No secure session caching

0 (turns off session caching)

2 minutes (default setting for the Microsoft® Windows NT® version 4.0 operating system)

120000

5 minutes (default setting for the Microsoft® Windows® 2000 operating system)

300000

10 hours (default setting for Windows Server 2003, Windows 2000 with Service Pack 2 [SP2] or later, and Windows XP)

36000000

 

For more information about configuring SSL session caching, including how to set the ClientCacheTime registry setting, see article 247658, "Configure Secure Sockets Layer Server and Client Cache Elements," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

The security services in Windows Server 2003 and IIS 6.0 are integrated into a number of operating system services. This means that you cannot monitor security features separately from other aspects of those services. Instead, the most common way to measure security overhead is to run tests that compare server performance with and without a security feature. Run the tests with fixed workloads and a fixed server configuration so that the security feature is the only variable.

In your tests of the effects of security services on performance, measure the following:

u        Processor activity and the processor queue. Security features like authentication, certificates, encryption, and the SSL protocol require significant processing; so it is important to balance the performance costs associated with these security features with your performance objectives.

When using security features, you are likely to see increased processor activity, in both privileged mode and user mode, and an increase in the rate of context switches and interrupts. If the processors on the server are not sufficient to handle the increased load, queues are likely to form.

If the SSL protocol is being used, Lsass.exe might consume an unexpected amount of CPU resources because SSL processing occurs in the Lsass.exe process. Custom hardware, such as cryptographic accelerators that perform encryption, can help. When you create certificates by using the certificate wizards provided in IIS, you can select a cryptographic service provider that uses cryptographic accelerators.

u        Physical memory used. Security features require that the system store and retrieve more user information.

u        Network traffic. You are likely to see an increase in traffic between the IIS-based server and the domain controller that is used for authenticating logon passwords and verifying IP addresses.

u        Latency and delays. The most obvious performance degradation resulting from complex security features like SSL is the time and effort involved in encryption and decryption, both of which use many processor cycles. Downloading files from servers by using the SSL protocol can be 10 to 100 times slower than downloading from servers that are not using SSL.


Important

It is recommended that you do not use a domain controller as a Web server. If a domain controller is running IIS, the proportion of processor use, memory, and network and disk activity consumed by domain services is likely to increase significantly. The increased activity can be enough to prevent IIS services from running efficiently.


For more information about IIS certificate wizards, see "Using Certificate Wizards" in IIS 6.0 Help.

To test a security feature like SSL, first run a stress client test with the security feature; then run the same test without it. Be sure to run the "with feature" and "without feature" versions of the test on varying workloads and multiple clients.

To eliminate the effects of unintended variations of the test conditions, repeat each test several times and average the results. Then, compare the results of the "with feature" and "without feature" tests. Consistent differences in the results of the tests are likely to indicate the overhead associated with the security feature. You can use these results for planning configuration changes in order to handle the security overhead.

For more information about testing with a stress client, see "Testing Applications with Stress Toolsiisrg_per_VHHP" earlier in this chapter.

WCAT is a particularly useful tool for determining security overhead. Run IIS 6.0 logging together with WCAT to count the number of logons and file accesses. In addition, you might use System Monitor, which includes a set of counters for monitoring user authentication.

For more information about obtaining and using WCAT, see "Using WCAT as a Stress Clientiisrg_per_YPGT" earlier in this chapter.

The Web Service and FTP Service performance objects include counters that report the number of anonymous and nonanonymous requests that are sent to each of these IIS 6.0 services. (The term nonanonymous is used instead of authenticated to account for custom authentication schemes that require data from the client other than, or in addition to, the user name and password, as is also the case with authentication.)

By themselves, these counters help you determine the number and proportion of each type of request. You can also use the counter values to estimate the effect of changing how you handle anonymous and nonanonymous users. For example, if most connections are anonymous, prohibiting anonymous requests has a more significant impact than if most requests are nonanonymous.

Analysis of data from these counters, together with general measures of server performance — such as the use and allocation of processor time, the size of processor queues, memory use, the number of disk reads and writes, and throughput — is even more useful. By analyzing the combined data, you can associate the effects of varying numbers and proportions of anonymous and nonanonymous users with changes in the performance of system components.

The counters that report the number of anonymous and nonanonymous requests are called Current Anonymous Users and Current NonAnonymous Users. In IIS 5.0, these counters actually displayed connections. In IIS 6.0, these counters count each request as a unique user.

Table 6.29 describes the counters for monitoring anonymous and nonanonymous requests. These counters are associated with the Web Service and FTP Service performance objects. The Anonymous Users and Nonanonymous Users counters display the number of anonymous and nonanonymous requests to the IIS 6.0 service when the values were last observed. They do not report averages or rates. These counters can exaggerate the number of requests because closed requests might not yet have been deleted when the counter is displayed.

Table 6.29   Counters for Anonymous and Nonanonymous Users

Object\Counter

Indicates

Web Service\Anonymous Users/sec

Web Service\NonAnonymous Users/sec

The number of requests per second that anonymous or nonanonymous users sent to the IIS 6.0 service. (These counters provide an instantaneous value rather than an average.) Note that IIS 6.0 counts each request as a new user.

Web Service\Current Anonymous Users

Web Service\Current NonAnonymous Users

FTP Service\Current Anonymous Users

FTP Service\Current NonAnonymous Users

The number of requests from anonymous or nonanonymous users that the server is currently processing. Note that IIS 6.0 counts each request as a new user.

Web Service\Maximum Anonymous Users

Web Service\Maximum NonAnonymous Users

FTP Service\Maximum Anonymous Users

FTP Service\Maximum NonAnonymous Users

The maximum number of anonymous or nonanonymous users that made concurrent requests to the service since the service was started. Note that IIS 6.0 counts each request as a new user.

Web Service\Total Anonymous Users

Web Service\Total NonAnonymous Users

FTP Service\Total Anonymous Users

FTP Service\Total NonAnonymous Users

The total number of requests that anonymous or nonanonymous users sent to the service since the service was started. Note that IIS 6.0 counts each request as a new user.

Web Service\Total Logon Attempts

FTP Service\Total Logon Attempts

The total number of requests that both anonymous and nonanonymous users sent to the service since the service was started.

 

If you prefer to use SNMP services to monitor the WWW and FTP services, IIS provides a set of SNMP counters that monitor anonymous and nonanonymous users. For more information about the SNMP Web counters, see "IIS 6.0 Performance Countersiisrg_cou_EWGJ" in this book.

The Web Service performance object includes a counter that displays not-found errors. Not-found errors result from client requests that were not satisfied because they included a reference to a Web page or a file that does not exist. These errors are identified by their HTTP status code number, which is 404. Many not-found errors occur because Web pages and files have been deleted or moved to another location.

You can use the Web Service\Not Found Errors/sec counter, described in Table 6.30, to track the rate at which not­found errors are occurring on your server. Alternatively, set an alert in Performance Logs and Alerts to notify the administrator when the rate of not-found errors exceeds a threshold.

Table 6.30   Counters for Not-Found Errors

Object\Counter

Indicates

Web Service\Not Found Errors/sec

The number of client read requests that were not satisfied because the URL did not point to a valid file.

 

An increase in not-found errors might indicate that a file has been moved without its link being updated. However, it can also indicate failed attempts to access protected documents, such as user lists and file directories.

An increase in not-found errors might also be related to IIS 6.0 security measures. When you perform a clean installation of IIS 6.0, the default settings ensure that IIS is installed in a secure, locked mode. This default installation serves only static HTTP content, such as .htm files; the request handlers for dynamic content, such as ISAPI and CGI, are disabled.

IIS 6.0 provides new substatus error codes that can help you determine why an HTTP 404 error (file or directory not found) occurred. For example, if a request is denied because an ISAPI extension or CGI is locked, a 404.2 error is returned, and a 404.3 substatus code indicates a MIME map restriction policy.

For more information about analyzing substatus codes, see "Troubleshooting IIS 6.0iisrg_trb_COTA" in this book. For more information about unlocking dynamic content, see "Common Administrative Tasksiisrg_tas_LPPR" in this book.

After you collect data to assess the effects of adding security features to your server configuration, use the results of your analysis to plan configuration changes that can help you handle the additional workload that is required to support security features. Consider the following options.

Upgrade or add processors

Security features in general and the SSL protocol in particular are usually processor-intensive. Because Windows Server 2003 security features are multithreaded, they can run simultaneously on multiple processors. Thus, adding processors can improve performance significantly and prevent the processors from becoming a bottleneck.

For best results, choose processors with large secondary (L2) cache space (up to 2 MB). When a security feature like SSL encrypts and decrypts data, much of the processor's time goes to reading and writing small units of data to and from main memory. If your server can store this data in the processor cache, the data is retrieved much faster.

Add memory

If security features cause increased paging or shortages in virtual memory, adding more memory can help. The physical memory used to support the security service consumes space that can be used to cache files. To accommodate peak use, allow for twice as much memory as required during times of average use while still maintaining 10 MB of available memory.


Important

Avoid adding disk space for security-related activity. Do not add disk space solely to support security features. Any increased disk activity associated with security features is likely to result from a shortage of physical memory, not from an actual need for more disk space. Security features such as the SSL protocol rely primarily on processors and physical memory, as opposed to disk space.


Use custom hardware

Custom hardware, such as cryptoaccelerator cards, can make a significant difference in the way that your server handles security overhead. Be sure to thoroughly test any nonstandard hardware to make sure that it is compatible with the other hardware and software that you use.

For more information about IIS security features, see "Security" in IIS 6.0 Help. For more information about setting up certificates and keys, see "Configuring SSL on Servers" in IIS 6.0 Help. For more information about enabling HTTP Keep-Alives, see "Enabling HTTP Keep-Alives to Keep Connections Openiisrg_per_ZFOO" later in this chapter.

Optimizing Performance Through Design

In addition to monitoring and tuning your server, you can optimize performance by improving the design and administration of your Web applications, by optimizing Web page design to create efficient Web pages, and by partnering with other groups in your organization who share the same network.

You can often improve the performance of your Web server by paying attention to the design and administration of your Web applications and by upgrading hardware components to support fast application response times.

Upgrading Hardware to Improve Application Performance

Several types of hardware upgrade can significantly improve application response times on your Web servers:

u        Upgrade or add processors. Web applications benefit from faster processors.

u        Add memory. Adding memory can improve application response times if applications are running within their own processes.

Optimizing Application Design

Check this list for general application design guidelines that can optimize performance.

u        Use static files wherever possible. Typically, static files require much less processor time than do files with dynamic content.

If you are generating pages dynamically to satisfy user preferences, consider substituting as many as 10 or 20 static variations for a single dynamic page. If you are generating dynamic pages to provide frequently updated data, redesign your application so that it generates a single static page on a fixed schedule and stores that page for retrieval until the next update.

u        Use managed code (C# or Microsoft® Visual Basic® .NET), Microsoft ASP.NET, or ISAPI applications. C# and Visual Basic .NET applications usually run faster than ASP applications because the run-time environment executes compiled code. All of these types of applications typically run faster than equivalent CGI applications.

u        Enable ISAPI and ASP.NET output caching where possible, which allows HTTP.sys to cache the response and serve requests for the applications from the kernel instead of transitioning to user mode. For more information about tuning ISAPI output caching, see "Tuning ASP Metabase Settingsiisrg_per_QHGZ" earlier in this chapter.

u        Avoid transitions from managed code to unmanaged code in your applications, if possible.

u        Enhance database-driven performance by using Microsoft SQL Server. Create and maintain good indexes to minimize I/O during database queries. Also, use stored procedures, which take much less time to execute and are easier to write than ASP scripts designed to do the same task.

u        Design your site so that applications push the processing load onto the client.

Client-side checks reduce roundtrips and help to avoid network latencies, conserve server-side resources, and allow changes to appear instantaneously to the user. For example, add client-side code to validate that forms are filled out with good data, such as checking that credit-card numbers have a correct checksum. However, the server must still validate the data, because malicious clients can send malformed data.

Optimizing the Design of ASP Applications

Check this list for ASP application design guidelines that can optimize performance.

u        Turn off ASP debugging, and verify that both the AppAllowDebugging and AppAllowClientDebug metabase properties are set to false.

u        Avoid storing apartment-threaded components in ASP application or session state. Remove Visual Basic objects from ASP Session state if they are apartment threaded.

u        Cache output from ASP if possible; if not, cache inputs to ASP if possible.

u        Convert scripts in ASP pages into COM objects. Scripts in ASP pages are interpreted; if a script involves one or more loops, converting it to a COM object can improve its performance considerably.

u        ASP is now able to run all of its threads in a multithreaded apartment (MTA). If your COM components are primarily free-threaded or both-threaded, running the ASP threads as MTA can improve performance significantly. To enable all ASP applications to run in an MTA, you can use the metabase property AspExecuteInMTA at the application level. For more information about designing ASP to run its threads in MTA, see "Configuring Applications to Use COM+ Services" in IIS 6.0 Help.

u        If an ASP script is more than 100 lines (counting lines of code in included files), consider creating a COM+ component to provide the same function. If COM+ components are written efficiently and debugged properly, they can offer 20 to 30 times the processing speed of a script for the same dynamic page.


Tip

The easiest way to measure the size of an ASP script with #include directives is to change the file name extension of the page from .asp to .stm, and then open the .stm file by using your browser. Use your browser's View Source command to display the .asp file and lines of code from the included files.


Optimizing Network Administration and Design

Check this list for network administration and design guidelines that can optimize performance.

u        Set HTTP expire headers for all images and for HTML so that proxy servers and browsers make fewer calls to the Web server. For information about setting an expiration date for Web site content, see "Using Content Expiration" in IIS 6.0 Help.

u        Use SSL certificates only when needed and only for content that requires security. Because SSL uses complex encryption that consumes considerable processor resources, it takes much longer to retrieve and send data from SSL-enabled directories. Therefore, only secure the files that contain or receive sensitive information, such as credit-card numbers or medical information. Also, keep these pages free of other elements that consume resources, such as images. For more information about implementing an acceptable level of security while preserving performance, see "Balancing Performance and Securityiisrg_per_HGXO" earlier in this chapter.

u        Minimize initialization processing wherever possible. For example, enable caching, when appropriate; on multiprocessor computers, assign processor affinity to better use CPU caching; and use HTTP compression for faster downloads. For information about caching, see "Monitoring Overall Server Memoryiisrg_per_QLKV" earlier in this chapter. For information about using compression on different file types, see "Using HTTP Compression for Faster Downloadsiisrg_per_ULEK" earlier in this chapter.

u        Run IIS in worker process isolation mode, which allows you to periodically restart worker processes assigned to an application pool (either manually or automatically by using preconfigured settings). Recycling worker processes can help minimize problems attributed to faulty Web applications.

u        Establish Web gardens, which are application pools that can run multiple worker processes.

u        Stress-test applications in your lab before you place them on a production server.

u        If you have a large installation with many FTP sites, each attached to a different IP port, your server might create too many backlog monitor threads (the system creates a thread for every 64 sites). The workaround for this is to disable the backlog monitor. To disable the backlog monitor, set the value of the DisableBacklogMonitor registry entry to 1 and then restart the FTP services. The DisableBacklogMonitor entry is located in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters


Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the <A HREF="http://go.microsoft.com/fwlink/?LinkID=4543" TARGET="_blank">Registry Reference</A> on the Windows Server 2003 Resource Kit companion CD or on the Web at http://www.microsoft.com/reskit.


u        If you expect a large spike in traffic on a particular page or set of pages, you can change that page or set it to static HTML for a few days. Switching from a dynamic page to static HTML can involve some redesign, but the effort is often worthwhile. For example, when many thousands of people, during a short period, traverse three or four scripted pages to get to a particular download page, your server uses a lot more resources than it needs to. To save time for your users, you can instead provide a temporary static front page that has simple navigation.

Creating a page-load performance profile provides a systematic way of looking at a Web page and recording its performance characteristics across a wide area network (WAN). A page-load performance profile incorporates the distance, congestion, and limited bandwidth that 99 percent of your users experience when accessing your site.

Page-load performance profiles can help you determine the following:

u        The impact of not setting expiration dates.

u        Which files are taking the longest to load.

u        Whether you have unneeded file content.

u        Where to reduce and consolidate files.

u        How long your pages take to load (on first access and second access).

u        Whether you need to enable or adjust your compression configuration.

To perform a page-load test, install the appropriate tools to collect data so that you can develop performance profiles by analyzing HTTP traffic. Network Monitor is a protocol analyzer that looks into packet-level detail. For more information about obtaining and using this tool, see "Network Monitor overview" in Help and Support Center for Windows Server 2003.

After obtaining page-load performance profiles for your Web pages, you can use the performance data to identify changes that you can make in order to optimize the performance of the Web pages.

Measure your page-load times by using the procedures that follow. After obtining a page-load performance profile, analyze the data and remove obstacles to the page's efficient performance by using the information in "Optimizing a Page-Load Performance Profileiisrg_per_YQCH" later in this chapter.

To obtain an accurate picture of a Web page's performance during normal use, you must obtain page-load performance data for the second access to a Web page as well as the first access. The first-access load time is usually much longer in duration than second-access load times. When a first-time user visits a Web page, the user's computer does not hold cached files from previous visits; hence, the user's browser must load all the files that are a part of the Web page. The procedure for measuring a Web page's first-access load time differs slightly from the procedure for measuring second-access load times.

Use this procedure to measure a Web page's first-access load time.


To measure a Web page's first-access load time

1.         Set up your WAN simulator to represent your 50th percentile domestic user. For example, your settings might be 60 milliseconds roundtrip delay, 50 kilobits per second, and no packet loss.

2.        Set the site that you want to test as the default home page for your browser.

3.        Browse to a site other than the one you are testing.

If you are still on the test site when you clear your cache, the site refreshes after you clear the cache, reloading the files that you want to clear.

4.        Clear the cache of all files by doing the following:

a.        On the Tools menu of Internet Explorer, click Internet Options.

b.        On the General tab, under History, click Clear History.

5.        Close your browser.

You must close TCP connections between tests, or your tests will be affected by TCP's slow-start algorithm, which retains the window size from the previous page load, producing inaccurate results.

6.        Start your Network Monitor capture.

7.        Open your browser to the test site (your new home page).

8.        Stop the capture when the page is fully loaded and run Network Monitor. Determine how much total time elapsed while the page was loading.

9.        Copy your data into a Microsoft® Excel worksheet for further analysis.


Important

Do not use CTRL+F5 (refresh the Web page — regardless of time stamp) as a substitute for this procedure. Although using CTRL+F5 is similar to this process in that it forces a full reload, it does not disconnect the TCP connections before the new page load.


When you test a Web page for its second-access load time, you can use files that are saved in the client's cache.


To measure a Web page's second-access load time

1.         Use the same WAN parameters and browser default settings that you used to determine first-access load time.

2.        Close your browser without clearing the cache.

3.        Restart your Network Monitor capture.

4.        Open your browser to the test page.

5.        Stop the capture when the page is fully loaded, and measure the time from the first TCP SYN from the client to the server, until the last byte is received.

6.        Copy the results to a second Excel worksheet for further analysis.

 


Important

Do not use F5 (refresh the Web page) as a substitute for this procedure because it does not provide the same results as a second page-load. Using F5 forces Internet Explorer to check the date on all cached files regardless of whether the dates will expire in the future.


After you complete your own page-load performance profiles, perform a page-load test against your competitors' sites, compare the results with your own performance data, and ask:

u        Which site is faster?

u        Does speed contribute to ratings?

u        Which sites will users choose to come back to?

By optimizing page-load performance profiles, you can provide more efficient Web sites for your users. Begin by making sure that HTTP Keep-Alives are enabled, enabling HTTP compression if appropriate for your Web sites, and setting expiration dates on the files associated with your Web pages. Then identify your slow-loading files, reviewing them for unneeded file content. Next measure your file quantity and size. Finally, determine port usage and minimize unneeded screen refreshes. After reviewing all these factors and optimizing your Web sites, obtain a new page-load profile to determine whether the changes significantly improve the efficiency of your Web site.

For additional tips for optimizing your Web sites, see "Best Practices for Creating Efficient Sitesiisrg_per_VYKA" later in this chapter. For instructions telling how to obtain a page-load profile, see "Obtaining a Page-Load Performance Profileiisrg_per_WVSE" earlier in this chapter.

Verify That HTTP Keep-Alives Are Enabled

Another item to verify is the "connection = keep-alive" state for each TCP connection. If keep‑alive connections are turned off, every file requires a new TCP connection. For small files, enabling HTTP Keep-Alives in IIS effectively doubles the number of roundtrips. For more information about HTTP Keep-Alives, see "Enabling HTTP Keep-Alives to Keep Connections Openiisrg_per_ZFOO" earlier in this chapter.

Set HTTP Compression

If you have Web sites that use large amounts of bandwidth, consider enabling HTTP compression to obtain faster transmission times between your server and compression-enabled browsers. The performance cost of compressing a static file is small and is typically incurred only once because the compressed file is stored in a compression cache.

The cost of expanding the file at the browser is minimal. Compressed files download faster, which makes them especially beneficial to the performance of any browser that uses a network connection with restricted bandwidth, such as a modem connection.

For more information about enabling HTTP compression, see "Using HTTP Compression for Faster Downloadsiisrg_per_ULEK" earlier in this chapter.

Set Expiration Dates on Files

A common performance mistake is omitting to set the expiration dates on the files associated with Web pages. When a user returns to a Web page, Internet Explorer already has most of the files for the page in its cache, but it does not use these files if the expiration dates are in the past. Instead, Internet Explorer sends a GET request to the server for the file, indicating the date of the file in the cache. If the file has not changed, the server sends a Not Modified message. This GET/Not-Modified sequence costs the client a roundtrip. For small files of 3 KB or less, this roundtrip is as expensive as getting the original file.


Important

You must be a member of the Administrators group on the local computer to perform the following procedure or procedures, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run IIS Manager as an administrator. At a command prompt, type runas /User:Administrative_AccountName "mmc %systemroot%\system32\inetsrv\iis.msc".


 


To set the expiration date in IIS 6.0

1.         In IIS Manager, right-click the file, and then click Properties.

2.        On the HTTP Headers tab, select the Enable Content Expiration check box, and then choose the option you want for setting a date.

You can set a specific date or you can choose to have IIS expire the file within a specified time, such as 30 days after the user loads it. For very small files, you can set the header to expire immediately.

To verify that expiration dates are working correctly, look for Not Modified messages in the HTTP response packet of your Network Monitor capture summary.

Identify Slow-Loading Files

Identifying which files are taking the longest to load often provides the best clues about what you need to improve. Causes of very long load times can include server capacity issues, network congestion, and large file content. Use the data that you collect from Network Monitor captures to identify how long each file takes to load. Visit a Web page several times and observe which files are regularly loaded most slowly. Multiple visits to a page help improve statistical veracity.

Remove Unneeded File Content

Files often contain clutter, such as tabs, spaces, new lines, and comments, that consumes up to 15 percent or more of a page. For production Web sites that are visited by millions of users, remove every bit of file content that is not absolutely necessary for the rendering of the page.

View the packet contents of your files with Network Monitor. Look for repetitive text such as <Option Value = data> statements that are used to insert text into drop-down lists. It takes much less space to add a few lines of code that sends an array (that reads the drop-down lists) to the client.

Measure File Quantity and Size

The number and size of files that you load on your Web site have a large impact on page-load times. Fewer large files load faster than many small files, as follows:

u        Number of files. For each file, HTTP must perform a GET-File. Each GET-File is at least a single roundtrip. If the files are on a new server that the user has not previously connected to, HTTP must also make another roundtrip to create a new connection. Roundtrips across a modem cost 250 milliseconds or more.

The optimal minimum number of files for a Web site is about four. Consider consolidating like files; for example, have only one .js or .css file instead of two or three.

u        Size of files. The TCP slow-start algorithm favors larger files. When a new connection is first opened, TCP sends a small number of packets in response to a GET-File. Thereafter, for each acknowledgement received by the server, TCP increases the number of response packets sent to the client.

Small files of 3 KB or less are complete in one roundtrip. Files larger than 20 KB receive only about 16 KB of data per roundtrip. The size of a file can make the difference between a very small bit rate of 1 to 10 kilobits per second (Kbps) and a high bit rate of 40 to hundreds of Kbps.

Determine Your Port Usage

Using HTTP 1.1, Internet Explorer can open a maximum of two ports to any one server and a maximum of four ports total. The best performance occurs when four ports are opened and are kept open to be reused by all the files. Reusing a port is a good thing; when TCP slow-start increases the window size for a file, the next file that uses the same port can also use the increased window size.

View your Network Monitor capture summary to determine how many ports were used during your page-load tests, and by which files. Keep in mind that measuring Web pages through a proxy server hides the true number of ports being used. The best tests from your office are conducted by using a direct connection to the Internet without a proxy.

Control Screen Refreshes

In a refresh request, Internet Explorer (the client) tells the server the date stamp of the version of a file that it has in its cache by using the "If-Modified-Since" header. IIS 6.0 then determines whether the file has been modified since that time. If the file is unmodified, IIS 6.0 replies with a brief "Not Modified" response.

In routine file updates for your Web site, do not copy files that have not been modified. A static HTML page is not retrieved during a screen refresh if it has not been updated. Some publication processes copy files that have not been modified, which gives the files new time stamps and thus "updates" them as far as the system is concerned. These files are downloaded even though they are actually unchanged. When you set up your publication process, make every effort to avoid this waste of resources.

For important, often-used Web pages, do the following.

Optimize settings

u        Set file expiration dates. By setting future expiration dates on each file at the IIS server, you can reduce second-access load times by 50 to 70 percent.

u        Enable HTTP Keep-Alives in IIS.

u        Author hyperlinks consistently because the Internet Explorer cache is case sensitive.

u        Use cache-control extensions. Internet Explorer version 5 introduced support for two extensions to the cache-control HTTP response header: pre-check and post-check.

u        Enable HTTP compression to increase efficiency of bandwidth use.

Use design elements judiciously

u        Standardize images. For example, if your site uses two images that are slightly different from each other, either in size, color, or design, standardize to a single image.

u        Reduce Graphics Interchange Format (GIF) image color depth or consider using Portable Network Graphics (PNG) format.

u        Eliminate unnecessary images that appear below the scroll bar. Users view these images less frequently; so weigh their value against their performance cost. For example, use text rather than images for arrows, lines, and bullets. Incorporate several small images into one large graphic (or remove some of the images). Substitute smaller images for large ones.

u        Use the most compact graphics format that supports the quality of image that you need. Images saved as a file type that is inherently large, such as a Tagged Image File Format (.tif), can increase download times; consider substituting a more compact format such as a Graphics Interchange Format (.gif) or a Joint Photographic Experts Group (.jpg) file. You might also consider compressing existing images.

Ensure that developers design scripts and code that load quickly

u        Reduce clutter. Space characters, tabs, and remarks often consume more than 20 percent of an .htm or an .asp file. Delete this clutter before you load the files on production servers.

u        Remove redundant tags. Consider using arrays to fill drop-down lists instead of repeating [<Option Value = data> data</Option>] again and again.

u        Use JavaScript (.js) files to consolidate commonly used scripts.

u        Reduce the number of small files. Build whole images instead of multiple component images. For tabs, use a single image map.

u        Consolidate multiple images and adjacent images into a single file.

u        Do not use nested <table> tags.

Test load times for your pages

You can use the following tools to test the load times for your Web pages:

u        WAN simulators

u        Network Monitor

u        Load simulators for the Internet environment

u        Reporting tools

In enterprise organizations, where corporate intranets might be accessed by employees in far-reaching parts of the country or the world, IT administrators in areas that share the intranet must work together to ensure optimal performance for all users. Take time to find out how the performance of other areas is affecting the performance of your applications and systems; then work with IT administrators in other areas to coordinate efforts to improve performance.

If the systems and applications that you manage depend on the performance of other systems and applications, use this guide to help you collaborate with your IT partners:

1.         Identify your partners:

u        Start early in the IT cycle to contact partners and find performance allies in other groups and on your own team. Obtain agreement to work together to maintain and improve performance, including upgrading, adding to, or changing your network components.

u        Determine how the performance of other systems and applications affects your systems and applications, and vice versa; then document the dependencies and share the data with your partners.

2.        Before you begin your design, obtain information about your users. You must know your users in order to set realistic goals for response times and system preferences. If possible, conduct usability tests to discover the actual needs, behaviors, and preferences of real users.

3.        Set performance goals for your group, and establish a timeline:

u        Set performance goals and test plans for your group.

u        Discuss key milestones in your timeline.

u        Identify competing priorities, especially conflicting priorities of partners outside your immediate group.

4.        Coordinate your plans and goals with your partners' plans and goals:

u        Share your goals, timeline, and milestones with your partners; then synchronize goals and timelines with them. Define terminology to ensure that everyone understands each goal and service level. Include a plan for communicating with your partners.

u        Write contracts, if needed, to set service level agreements for performance and to balance competing priorities so that other groups' priorities do not adversely affect yours (and vice versa).

u        Establish baseline requirements for operating systems and hardware.

u        Establish guidelines for how to monitor any mutual performance dependencies. Establish minimum testing standards. Establish a system for logging bugs against performance problems.

5.        Design the systems and applications for your group to minimize their impact on other components:

u        Design your client systems so they do not put unnecessary load on servers. For example, ensure that clients' browsers are compression-enabled, and enable HTTP compression of static files on your Web server to provide faster transmission times.

u        Test to identify and minimize unnecessary client requests, such as requests from impatient users who make numerous attempts to access the same page. It is recommended that you set the AspQueueConnectionTestTime metabase property so that your server does not process abandoned requests, enable HTTP Keep-Alives, and set up caching to minimize requests from clients' Web browsers.

These resources contain additional information and tools related to this chapter.

Related Information

u        "Analyzing Log Filesiisrg_log_GADT" in this book for information about using IIS logs to monitor and tune performance.

u        "Common Administrative Tasksiisrg_tas_LPPR" in this book for step-by-step instructions to help you complete many of the tasks described in this chapter.

u        "Troubleshooting IIS 6.0iisrg_trb_COTA" in this book for information about troubleshooting performance.

u        "Web Server Scalabilityiisrg_sca_OVERVIEW" in this book for information about IIS 6.0 capacity planning and scalability.

u        Article 247658, "Configure Secure Sockets Layer Server and Client Cache Elements," in the Microsoft Knowledge Base for information about configuring SSL session caching, including how to set the ClientCacheTime registry setting. To find this article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

u        Article 313064, "Monitor Web Server Performance by Using Counter Logs in System Monitor in IIS," in the Microsoft Knowledge Base for information about creating counter logs, including baseline IIS logs. To find this article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

u        The Windows System Resource Manager — Fast Facts link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources for information about using Windows System Resource Manager.

u        Microsoft Application Consulting and Engineering (ACE) Team, Performance Testing Microsoft .NET Web Applications. Redmond, WA: Microsoft Press, 2003. Read this source for information about how to perform stress testing by using Microsoft Application Center Test (ACT), how to use System Monitor and Network Monitor, and how to conduct an application network analysis.

Related IIS 6.0 Help Topics

u        "Enabling Logging" in IIS 6.0 Help, which is accessible from IIS Manager, for information about performance logging.

u        "Limiting Connections" in IIS 6.0 Help for information about setting global and individual site connection limits.

u        "Quality of Service" in IIS 6.0 Help for information about the QoS features in IIS 6.0.

u        "Security" in IIS 6.0 Help for information about IIS 6.0 security features.

u        "Web Application Guide" in IIS 6.0 Help for information about Web application development, including ASP.NET and ASP applications.

Related Windows Server 2003 Help Topics

For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only check box.

u        "Analyzing performance data" in Help and Support Center for Windows Server 2003 for information about analyzing log data and a list of acceptable values for counters.

u        "Performance console overview" in Help and Support Center for Windows Server 2003 for information about Windows performance monitoring tools.

u        "Monitoring performance from the command line" in Help and Support Center for Windows Server 2003 for information about command-line tools that you can use to monitor performance.

u        "The TCP/IP model" in Help and Support Center for Windows Server 2003 for information about how the OSI model relates to the TCP/IP reference model.

Related Tools

u        The logman command

Use the logman command to schedule performance counter and event trace log collections on local and remote systems. For more information about the logman command, see "Logman" in Help and Support Center for Windows Server 2003.

u        Log Parser tool (LogParser.exe)

Use the Log Parser tool to extract data from the raw file. The Log Parser tool and its accompanying user documentation are included in the IIS 6.0 Resource Kit Tools. You can install the IIS 6.0 Resource Kit Tools, which include Help documentation, by running IIS60rkt.exe from the Internet Information Services (IIS) 6.0 Resource Kit companion CD.

u        The start netmon command

Use the start netmon command to start the Network Monitor user interface from the command line. You can also specify parameters for capturing and filtering frames. For more information about using this command-line option, see "Managing Network Monitor from the command line" in Help and Support Center for Windows Server 2003.

u        Web Capacity Analysis Tool (WCAT), which contains a stress client tool (Wcclient.exe) and a controller tool (Wcctl.exe).

Use WCAT to perform stress testing. You can obtain WCAT and its documentation from the Internet Information Services (IIS) 6.0 Resource Kit companion CD. You can install the Resource Kit Tools by running IIS60rkt.exe from the companion CD.

 

 



Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

0 Comments: