Chapter 5 - Monitoring and Tuning Your Server

Article
12/09/2009

Monitoring is an essential part of server administration. By monitoring the server's performance, you can spot problematic trends as they develop, and take steps to prevent them from turning into emergencies. Monitoring also helps you decide when to upgrade your hardware, and whether upgrades are actually improving your server's performance appropriately. Also, while some server problems are obvious, some develop over time; and unless you have a baseline against which to judge and compare, you can be blind-sided by a problem that you might have avoided. This chapter is intended to help you use the System Monitor and other tools to develop both a baseline and a monitoring strategy to help you track the performance of your server.

Tuning your server improves the client experience, helps you avoid some bottlenecks, and sometimes extends the interval between hardware upgrades. You can use the information from your monitoring program to decide how you should best tune your server.

This chapter does not discuss client connections or client-side performance, except to the extent that the client's performance is controlled by the server.

Using This Chapter

This chapter suggests several approaches to monitoring and improving the performance of a site running Internet Information Services (IIS) 5.0 with Microsoft® Windows® 2000 Server or Microsoft® Windows® 2000 Advanced Server. It is intended as a technical guide for administrators, but should be useful for anyone with one or more servers running IIS 5.0. The sections in this chapter discuss the following topics:

Memory Memory is discussed first because memory shortages often manifest themselves as poor performance in other components, especially processors and disks. It is important to rule out a memory shortage before investigating other components.

This section presents an overview of some techniques for determining whether a computer has adequate physical memory to be an efficient Internet server. It discusses how IIS 5.0 uses physical memory, including the IIS Object Cache, IIS Template Cache, and IIS Script Engine Cache, as well as the operating system's File System Cache, In addition, it includes suggestions for tuning some server parameters to improve memory use. It also covers Transmission Control Protocol (TCP) sockets.
Preventing Processor Bottlenecks This section presents a brief discussion of tools and strategies for monitoring processor use in single-processor and multiple-processor computers running IIS 5.0, and for preventing the processor from becoming a system bottleneck. It provides information about the role of the processor in servicing client connections and requests, and it includes tips on tuning in order to balance processor load.
Network I/O This section offers some techniques for measuring how much data a network configuration is able to transmit during periods of average and peak use. It includes some suggestions for capacity planning based on the number of files and connections the server is expected to handle.
Web Applications Applications can be responsible for poor performance and inefficient processor and memory use. This section builds on the monitoring techniques discussed in the memory and processor sections. It suggests some ways to monitor the basic aspects of application performance, and explains why some applications perform better than others on IIS 5.0. It also includes some suggestions for optimizing your Web applications, and for mitigating the effects of poor application performance.
Monitoring Security Overhead This section presents a brief discussion of some techniques for monitoring the performance overhead associated with some common security strategies, such as integrated Windows authentication and the Secure Sockets Layer (SSL) protocol.
Tools This section is a short list of some monitoring and performance-testing tools that you can use with Windows 2000 Server and IIS 5.0.

Memory

With memory, more is almost always better. But just pouring more RAM into your server won't necessarily solve your problems, and certainly won't optimize your server. It is important to determine whether you are making good use of the memory you have.

Memory Allocation

The largest "chunk" of activity in Windows 2000 Server is a process. The physical RAM available to a process is called its working set. If the needs of a process exceed the amount of available RAM, that is, if the process is not able to store all of its code and frequently-used data in physical memory, some of the information must be stored elsewhere, usually on disk (as virtual memory). This causes an increase in the amount of disk activity, which slows down the server. Some memory contains information (typically code) that is used often, and it should not be sent off to disk because this will result in serious performance degradation. A memory region of this type is designated as "nonpageable."

Within each process, Windows 2000 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 5.0, for example, are not pageable. Sockets also use nonpageable memory. If too many sockets and nonpaged threads are created, the system runs out of nonpaged pool memory and a "bottleneck" occurs. (This can happen, for example, during some forms of denialofservice attack, in which the server is barraged with requests. For more information, see "Security" in this book.

Memory Management

The Windows 2000 Server memory system is largely self-tuning. The Virtual Memory Manager and the Cache Manager adjust cache sizes, the working sets of processes, the paged and nonpaged memory pools, and paging files on disk to produce the most efficient use of memory. Similarly, IIS 5.0 regulates the size of the IIS Object Cache. Therefore, the primary purpose of monitoring memory in a Windows 2000 operating system–based server running IIS 5.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.

There are several major areas to look at when monitoring memory usage on a Web server. The next section discusses them.

Memory Requirements of a Server Running IIS 5.0

Web servers use memory in several ways. A server running IIS 5.0 needs to have enough physical memory to accommodate the following:

The Program Code for IIS 5.0 This code occupies about 2.5 megabytes (MB) of memory with all services running simultaneously. It is part of the working set of the IIS 5.0 process, Inetinfo.exe, and can–but for performance reasons should not be–paged to disk. (By default, Internet Server Application Programming Interface (ISAPI) dynamic-linked libraries (DLLs) run in a separate memory space in IIS 5.0.)

Note: In addition, each connection adds approximately 10 kilobytes (KB) to the size of the working set. Thus, when there are 1,000 simultaneous connections, the working set expands by about 10 MB.
The IIS Object Cache Objects that are costly to retrieve and frequently reused by the service, such as file handles, file directory listings, and so on, are stored in the IIS Object Cache, a cache maintained by the IIS 5.0 service. The IIS Object Cache is also part of the working set of the IIS 5.0 process, Inetinfo.exe, and can be paged to disk.
The IIS Template Cache and the IIS Script Engine Cache The IIS Template Cache is a relatively small area of memory that holds, for example, pointers to Script Engines. The IIS Script Engine Cache holds precompiled scripts in Active Server Pages (ASP) ("Script Engines") that are ready to run. The IIS Template and Script Engine caches are part of the dllhost space by default in IIS 5.0, because scripting is run in the out-of-process pool. (Instances of dllhost in IIS 5.0 are equivalent to instances of Mtx.exe in IIS 4.0.) If this setting is changed, however, and scripting is brought in process, they become part of Inetinfo.exe. For more information about running applications in the out-of-process pool, see "Administering an ISP Installation" in this book.
The File System Cache Web page files that are frequently accessed are stored in the operating system's File System Cache, an area of physical memory reserved for items that are used frequently and repeatedly. The remaining files are stored on disk until needed.

Overall Memory Usage by the Server. (This is particularly important on multipurpose servers.) This category includes:
- IIS 5.0 Log Files IIS 5.0 maintains one memory-mapped file for each site that has logging enabled. These files are mapped in 64-KB chunks. The mapped segments of the log files are part of the working set of the IIS 5.0 process. Logged data also appears in the File System Cache because data is cached when the file-mapping objects are written to disk.
- TCB Table TCP maintains a hash table, a scheme for providing rapid access to data items, of Transmission Control Blocks (TCBs) that store data for each TCP connection. A control block is attached to the table for each active connection and is deleted shortly after the connection is closed. The TCB table is part of the operating system's nonpaged memory pool. As such, the TCB table must remain in physical memory; it cannot be paged to disk. TCP sockets are also maintained in nonpaged memory.
- HTTP Connection Data Structures HTTP maintains pageable data structures to track its active connections. When these data structures are in physical memory, they are counted as part of the working set of the IIS 5.0 process.
- Pool Threads The threads that execute the code for IIS 5.0 services are stored in the nonpaged pool in physical memory, along with other objects used by the operating system to support IIS 5.0. Threads in the nonpaged pool must remain in physical memory; they cannot be paged to disk.

Cache sizes, of course, vary depending on the files used by your server and its clients, and on the amount of physical memory present in the server.

Memory consumption is greater for dynamic pages and depends heavily on the type of application involved. For example, an ASP page that formats database tables containing thousands of rows consumes far more memory than even a fairly large static page.

In general, it's good to have at least 256 MB of RAM; you'll want more in a server that is performing memory-intensive tasks.

Monitoring Overall Server Memory

IIS 5.0 is well integrated with the Windows 2000 operating system. Because of this, IIS 5.0 services derive many benefits from the system architecture, including the Windows 2000 Server security model, remote procedure call (RPC) communication, messaging, the file systems, and other operating system services. Thus, monitoring memory for IIS 5.0 begins with monitoring overall server memory, particularly on a multipurpose server.

Monitoring the physical memory of a server running IIS 5.0 involves measuring the size of the areas in physical memory used by IIS 5.0 and assuring that enough space is available to contain the elements IIS 5.0 needs to store. The physical memory space should be sufficient for normal operation and for routine peaks in demand; but your site may also encounter occasional spikes. If it does, you must decide how much degradation in performance (if any) you will allow at those times. Routine peaks on most sites reach about twice the average amount of utilization, whereas spikes can easily be a full order of magnitude beyond the average.

The Windows 2000 virtual memory system is designed to be self-tuning. The Virtual Memory Manager and Cache Manager within Windows 2000 adjust the size of the File System Cache, the working sets of processes, the paged and nonpaged memory pools, and the paging files on disk in order to produce the most efficient use of available physical memory. Similarly, the IIS 5.0 service regulates the size of the IIS Object Cache. Therefore, the primary purpose of monitoring memory in a Windows 2000–based server running IIS 5.0 is to make sure that the server has enough physical memory, not to adjust the size of each memory component, as might be the case with other operating systems.

Memory shortages frequently show up as or appear to be problems in other components. Thus, when your server has a problem (its response time increases, for example, or it cannot handle all of the requests it is receiving), it's a good idea to check memory first.

Memory Monitoring Specifics

This section is a brief review of the most important memory monitoring techniques*.* Many performance monitoring tools measure memory use system-wide and according to each process. These tools include Task Manager as well as the System Monitor, which is usually referred to as PerfMon (Perfmon.msc, supplanting the older Perfmon.exe). These are Windows 2000 Server administrative tools built into Windows 2000 Server. In addition, there are various tools included on the Microsoft® Windows® 2000 Server Resource Kit companion CD or in Windows 2000 itself, the latter of which include Process Monitor (Pmon.exe), Process Viewer (Pviewer.exe), Process Explode (Pview.exe), and Performance Data Log Service, which is usually referred to as PerfLog, (Pdlcnfig.exe and Pdlsvc.exe). PerfLog and PerfMon can measure memory use over time. PerfMon, in particular, can read and log data from software performance counters that are built into IIS 5.0 and the Windows 2000 operating system. For more information about PerfMon, see "The System Monitor" in this chapter.

Monitor Available Memory Compare the total physical memory that is available to Windows 2000 with the available memory remaining when you are running all server services. To gather more reliable data, log this value over time, making certain to include periods of peak activity. The system attempts to keep the amount of available bytes at 4 MB or more, but it is prudent to keep at least 5 percent of memory (rather than a specific number of MB) available for peak use.

To track available memory, log the Computername\ Memory\ Available Bytes counter. ("Computername" indicates the name of the computer you are monitoring, if it isn't the same one on which PerfMon is running. This indicator is not explicitly shown in the names of most of the counters listed in this chapter, but is generally applicable.)

Monitor Paging Continuous high rates of disk paging indicate a memory shortage.
- Number of Hard Page Faults If a process requests a page in memory and the system cannot find it at the requested location, this constitutes a page fault. (If the page is elsewhere in memory the fault is called a soft page fault. If the page must be retrieved from disk, the fault is called a hard page fault.) The system also counts a page fault on a file access if the requested page is not found in the File System Cache and must be retrieved from storage. The page fault counters do not distinguish between hard and soft faults, so you must combine counter information to deduce the number of hard faults.
  
  To track paging, log the following counters: Memory\ Page Faults/sec, Memory\ Cache Faults/sec, and Memory\ Page Reads/sec. The first two of these track working sets and the File System Cache. The Page Reads counter helps you track hard page faults: a high rate of page faults coupled with a high rate of page reads (these also show up in the Disk counters) indicates a high rate of hard faults.
Monitor the File System Cache The File System Cache is the working set of the file system. This cache is a reserved area in physical memory where the file system stores its recently used and frequently used data. By default, the system reserves about 50 percent of physical memory for the File System Cache, but the system trims the cache if it is running out of memory. A server running IIS 5.0 functions like a specialized file server, and a large and effective File System Cache is vital to its efficient operation. For more information, see "Monitoring the File System Cache" in this chapter.
Monitor the Size of the Paging Files The paging files on disk back up committed physical memory. The larger the paging file, the more memory the system can commit. Windows 2000 itself creates a paging file on the system drive; you can create a paging file on each logical disk, and you can change the sizes of the existing files. In fact, striping a paging file across separate physical drives (use drives that do not contain your site's content) improves paging file performance. Remember, in any case, that the paging file on the system drive should be at least twice the size of physical memory, so that if a crash occurs the system can write the entire contents of RAM to disk. This socalled "core dump" (a term that originated when memory was built of discrete magnetic cores, long before chips were invented) can help you recover data and determine the cause of the crash. To monitor the paging files, log the Computername\ Process\ Page File Bytes: Total counter.
Monitor the Size of the Paged and Nonpaged Memory Pools 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. On servers running IIS 5.0, threads that service connections are stored in the nonpaged pool, along with other objects used by the service, such as file handles.

To monitor the pool space for all processes on the server, log the Computername\ Memory\ Pool Paged Bytes and Computername\ Memory\ Pool Nonpaged Bytes counters. To monitor the pool space used directly by IIS 5.0, log the Computername\ Process\ Pool Paged Bytes: Inetinfo and Computername\ Process\ Pool Nonpaged Bytes: Inetinfo counters.

Tuning TCP Sockets

In IIS 4.0, TCP sockets were allocated on a per-Web-site basis. This meant that if you created thousands of sites on one server, performance suffered. By contrast, in IIS 5.0 sockets are allocated on a per-port basis. Regardless of how many Web sites you place on any particular port, they share the sockets allocated to that port. Of course, if you put a huge number of sites on one port, performance can still suffer; if you have a mission-critical site, you can disable socket pooling for that site to avoid the risk. The relevant property is a metabase entry (MD_DISABLE_SOCKET_POOLING), which you can set at /LM/W3SVC/X (where X is the number of the site) to revert back to the IIS 4.0 default behavior.

If you choose to disable socket pooling, you should do so only at the site level, so that other (noncritical) sites can continue to take advantage of this feature. This property is not available in the IIS snap-in; you can only set it by scripting. For information about setting metabase properties, see the "Active Server Pages Guide" topic of the IIS 5.0 online product documentation.

If you have a real need to disable socket pooling globally, type the following at the command prompt:

c:\inetpub\adminscripts\cscript adsutil.vbs set w3svc\disablesocketpooling true

The command prompt will reply:

disablesocketpooling : (BOOLEAN) True

Note: If pooling is enabled and you set bandwidth throttling for a site in the pool, the setting affects all the other sites as well. For this reason, it's a good idea to disable pooling for any throttled site(s).

As an alternative to using the command line, you can change metabase settings with Metabase Editor, a tool that is distributed on the Resource Kit companion CD.

Monitoring the Working Set of the IIS 5.0 Process

A server running IIS 5.0 must have enough physical memory to support the IIS 5.0 working set.

The system continually adjusts the size of the working set of a process as the process runs. The amount of space the system provides to the working set depends on the amount of memory available to the system and the needs of the process.

This next section suggests methods for monitoring the size of the IIS 5.0 working set over time and explains how to determine whether the working set of the IIS 5.0 process is large enough.

About the Inetinfo Working Set

The Inetinfo working set does not have a fixed size. The requirements of the working set vary depending upon the number of connections maintained, the number and size of files, and the use of other supporting services, such as security features and logging.

IIS 5.0 runs in a pageable user-mode process called Inetinfo.exe. When a process is pageable, the system can remove part or all of it from RAM and write it to disk if there isn't enough free memory. If part of the Inetinfo process is paged to disk, the performance of IIS 5.0 suffers. It's extremely important to be sure that your server or servers have enough RAM to keep the entire Inetinfo process in memory at all times. The Web, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) services run in the Inetinfo process. Each of the current connections is also given about 10 KB of memory in the Inetinfo working set.

ISAPI DLLs, including ASP, can run in or out of process; in IIS 5.0, ASP processing is done in pooled out-of-process mode by default, and should certainly be run out of process during development and testing. The out-of-process pool is part of the dllhost space, the size of which you can also monitor.

The working set of the Inetinfo process should be large enough to contain the IIS Object Cache, data buffers for IIS 5.0 logging, and the data structures that the Web service uses to track its active connections.

Using the System Monitor to Monitor the IIS 5.0 Working Set

You can use PerfMon to monitor the working set of Inetinfo.exe. Because ISAPI DLLs run in the out-of-process pool by default, you'll need to monitor them separately from Inetinfo unless you've changed that setting; and you need to be aware that out-of-process counter information is summed. This makes it difficult to single out any one process or application. (If your site uses custom ISAPI DLLs, those DLLs should incorporate their own counters so that you can monitor them individually.) To track ISAPI DLLs, you should monitor dllhost counters in the Process counter set. You can also monitor the IIS Object Cache.

For more information about running applications in the out-of-process pool, or separately out of process, see "Administering an ISP Installation" in this book.

Table 5.1 lists relevant counters for monitoring the Inetinfo process.

Table 5.1 Counters for Monitoring the IIS 5.0 Working Set

Counter	Indicates
Computername\ Memory\ Available Bytes	The amount of physical memory remaining and available for use, in bytes. This counter displays the amount of memory not currently used by the system or by running processes. It displays the last observed value, not an average. The operating system attempts to prevent this value from falling below 4 MB. It often trims the working sets of processes to maintain the 4 MB minimum available memory.
Computername\ Process\ Working Set: Inetinfo	Size of the working set of the process, in bytes. This counter displays the last observed value, not an average over time.
Computername\ Process\ Page Faults/sec: Inetinfo	Hard and soft faults in the working set of the process.
Computername\ Memory\ Page Faults/sec	Hard and soft faults for all working sets running on the system.
Computername\ Memory\ Page Reads/sec	Hard page faults. This counter displays the number of times the disk is read to satisfy page faults. It displays the number of read operations, regardless of the number of pages read in each operation. A sustained rate of 5 reads/sec or more can indicate a memory shortage.
Computername\ Memory\ Pages Input/sec	One measure of the cost of page faults. This counter displays the number of pages read to satisfy page faults. One page is faulted at a time, but the system can read multiple pages ahead to prevent further hard faults.

You should log this data for several days. You can use Performance Logs and Alerts in PerfMon to identify times of unusually high and low server activity.

Analyzing the Working Set Data

The following sections describe how to use data about the Inetinfo working set to determine if the server has enough memory to support IIS 5.0 efficiently.

Available Bytes and the Inetinfo Working Set

When the amount of available memory falls below about 4 MB, the system attempts to provide more available bytes 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.

If the system has sufficient memory, it can maintain enough space in the Inetinfo working set so that IIS 5.0 rarely needs to perform disk operations. One indicator of memory sufficiency is how much the size of the Inetinfo process working set varies in response to general memory availability on the server.

As Table 5.1 indicated, you can use the Computername\ Memory\ Available Bytes counter as an indicator of memory availability and the Computername\ Process\ Working Set: Inetinfo counter as an indicator of the size of the IIS 5.0 working set. Be sure to examine data collected over time, because these counters display the last value observed, rather than an average.

Tip You may want to have PerfMon alert you if the number of available bytes dips below about 5 percent of the amount of physical RAM on the server, or below a minimum of about 10 MB on small servers.

Page Faults and the Inetinfo Working Set

When you look at page faults, compare your data on the size of the Inetinfo working set to the rate of page faults attributed to the working set. As Table 5.1 showed, you can use the Computername\ Process\ Working Set: Inetinfo counter as an indicator of the size of the working set, and the Computername\ Process\ Page Faults/sec: Inetinfo counter to indicate the rate of page faults for the IIS 5.0 process. When you have reviewed data on the varying size of the Inetinfo working set, you can use its page fault rate to determine whether the system has enough memory to operate efficiently. If the system is not able to lower the page fault rate to an acceptable level, you should add memory to improve performance.

ASP Caching

In addition to various static files, there are two special ASP caches, the IIS Template Cache and the IIS Script Engine Cache. By default, scripts run in the out-of-process pool, so the IIS Script Engine Cache is part of dllhosts rather than Inetinfo. This is also true if you run ASP separately out of process. If you move ASP processing in process, however, these two caches become part of the Inetinfo process. The final HTML that results from executing Script Engines is not cached, because in many cases that output can vary each time the script is executed. For more information, see "Tuning the ASP Queue and Thread Pool" in this chapter.

The IIS Object Cache

The IIS Object Cache is part of the working set of the IIS 5.0 process in physical memory. Because of this, the IIS Object Cache can be paged to disk if memory is not sufficient to support a large enough working set for the IIS 5.0 process. It is important either to provide enough physical memory to maintain the IIS Object Cache in the working set, to reduce ObjectCacheTTL so that the cache is flushed more often, or both.

Using PerfMon to Monitor the IIS Object Cache

There are five performance objects for measuring IIS 5.0 performance:

Internet Information Services Global
Web Service
ASP (though, by default, ASP processing is external to Inetinfo)
FTP Service
SMTP Service

Table 5.2 lists the counters recommended for monitoring the IIS Object Cache. You should log the counters over time to record trends in the size, content, and effectiveness of the IIS Object Cache.

Table 5.2 Counters for Monitoring the IIS Object Cache

Counter	Indicates
Internet Information Services Global\ Cache Hits Internet Information Services Global\ Cache Misses Internet Information Services Global\ Cache Hits %	A measure of the efficiency of the IIS Object Cache. These counters demonstrate how often data sought in the IIS Object Cache is found. Internet Information Services Global\ Cache Misses indicates how often the system must search elsewhere in memory or on disk to satisfy a request. The first two of these counters (Cache Hits and Cache Misses) display totals since the service was started. Internet Information Services Global\ Cache Hits % displays an instantaneous value, not an average over time.
Internet Information Services Global\ Cache Flushes	How many times an object was deleted from the IIS Object Cache, either because it timed out, or because the object changed.
Internet Information Services Global\ Objects Internet Information Services Global\ Directory Listings	The total number of objects currently stored in the IIS Object Cache. Directory Listings is a subset of the Objects counter. At any given time, the difference between the total number of objects and the number of Directory Listings is equal to the number of other objects stored in the cache. The Directory Listings counter is most important to servers running the FTP service.

Analyzing the Performance of the IIS Object Cache

As Table 5.2 shows, cache performance is judged by how often objects sought in the cache are found. Frequent cache misses result in disk I/O and decreased performance. There are no fixed standards for cache performance, although a value of 80 to 90 percent for Cache Hits % is considered to be excellent for sites with many static files. If Cache Hits and Cache Hits % are very low, or if Cache Misses is quite high, the cache could be too small to function effectively. Adding memory increases the size of the cache and should improve its performance.

Cache flushes can also affect the performance of the IIS Object Cache. Cache flushes are regulated, in part, by an internal timer. The timer activates the object-cache scavenger, which deletes expired objects. Objects are flushed from the cache if they change, or if they time out before they are reused.

To measure cache flushes, compare the number of cache flushes over time to the number of cache misses and to the rate of page faults in the Inetinfo process (as indicated by the Process\ Page Faults/sec: Inetinfo counter). It is important to observe these values over time. Like the other global IIS 5.0 counters, Cache Flushes displays an instantaneous value, not an average. If a high rate of cache flushes is associated with elevated cache misses and page faults, it is possible that the cache is being flushed too frequently.

If you suspect that cache flushes are occurring too often or not often enough, you can change the rate at which unreferenced objects are flushed from the IIS Object Cache. Make sure your server has ample memory before you increase the time between flushes. The cache flush time defaults to 30 seconds; to change it, add the ObjectCacheTTL key to the registry if it is not already present. Put this key in the following registry location:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Inetinfo \Parameters

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft® Management Console (MMC) whenever possible.

If you increase ObjectCacheTTL, the cache size increases because files stay in the cache longer. Be sure your server has enough physical memory to support the increased load.

Monitoring the File System Cache

The File System Cache is maintained by the Cache Manager in Windows 2000 for use by all processes. This section explains how IIS 5.0 uses the File System Cache, how to monitor the size and efficiency of the cache, and how to interpret the data you collect.

How IIS 5.0 Uses the File System Cache

IIS 5.0 relies on the operating system to store and retrieve frequently-used Web pages and other files from the File System Cache. The File System Cache is particularly useful for servers of static Web pages, because Web pages tend to be used in repeated, predictable patterns.

Also, IIS 5.0 always reads sequentially. Sequential reading takes advantage of a Cache Manager feature called a read ahead. This occurs when the Cache Manager's predictive algorithms detect sequential reading and begin to read larger blocks of data in each read operation. Read aheads can provide a significant performance boost to a process.

IIS 5.0 uses both the File System Cache and the IIS Object Cache, sometimes together. When a thread belonging to an IIS 5.0 service needs to open a file, the thread requests a file handle from the operating system. When it receives the handle, the thread uses the handle to open the file. Then, if space permits, the thread stores the handle in the IIS Object Cache and the system stores the file data in the File System Cache. Later, if that thread (or any other thread) needs the file, the file handle can be retrieved from the IIS Object Cache and the file contents can be retrieved from the File System Cache.

Using PerfMon to Monitor the File System Cache

There are several counters in the Memory and Cache performance objects that you can use to monitor the size and effectiveness of the File System Cache. Table 5.3 lists these counters.

Table 5.3 Counters for Monitoring the File System Cache

Counter	Indicates
Memory\ Cache bytes	The size of the cache, in bytes. This counter displays the last observed value; it is not an average.
Memory\ Cache faults/sec	How often data sought in the File System Cache is not found there. The count includes faults for data found elsewhere in memory, as well as faults that require disk operations to retrieve the requested data. This counter displays the number of faults, regardless of the number of pages retrieved in response to the fault.
Cache\ Copy Reads/sec	The frequency of reads from pages of the File System Cache that involve a memory copy of the data from the cache to the application's buffer. This is a method used by the LAN Redirector, the LAN Server (for small items), and the disk file systems.
Cache\ Fast Reads/sec	The frequency of reads from the File System Cache that bypass the installed file system and retrieve the data directly from the cache. Normally, file I/O requests invoke the appropriate file system to retrieve data from a file. However, this path permits direct retrieval of data from the cache without file system involvement, if the data is in the cache. Even if the data is not in the cache, one invocation of the file system is avoided.
Cache\ MDL Reads/sec	How often the system attempts to read large blocks of data from the cache. Memory Descriptor List (MDL) Reads are read operations in which the system uses a list of the physical address of each page to help it find the page. MDL Reads are often used to retrieve cached Web pages and FTP files.
Cache\ Pin Reads/sec	How often the system attempts to read recently accessed blocks of data from the cache. This counter is more accurate for ASP content than the MDL Reads/sec counter is. Pin counters display reads of cache data that is held because it has just been read or written. They reflect cache data that is used repeatedly.
Cache\ MDL Read Hits %	How often attempts to find large sections of data in the cache are successful. You can use the Cache\ MDL Read Hits % counter to calculate the percentage of MDL misses. Misses are likely to result in disk I/O.
Cache\ Pin Read Hits %	How often attempts to find recently accessed sections of data in the cache are successful. This counter is more accurate for ASP content than the MDL Read Hits % counter is. You can use the Cache\ Pin Read Hits % counter to calculate the percentage of misses. Misses are likely to result in disk I/O. Pin counters display reads of cache data that is held because it has just been read or written. They reflect cache data that is used repeatedly.
Cache\ Data Maps/sec	How often pages are mapped into the cache from elsewhere in physical memory or from disk. To measure the percentage of data maps from elsewhere in physical memory, use Cache\ Data Map Hits %. 100 minus the value of Cache\ Data Map Hits % is the percentage of data maps retrieved from disk.
Cache\ Read Aheads/sec	A measure of sequential reading from the cache. When the system detects sequential reading, it anticipates future reads and reads larger blocks of data. The read ahead counters are a useful measure of how effectively an application uses the cache.
Memory\ Page Faults/sec	Hard and soft faults in the working set of the process. This counter displays the number of faults, without regard for the number of pages retrieved in response to the fault.
Memory\ Page Reads/sec	Hard faults in the working sets of processes and in the File System Cache.

Note: You should log this data over several days, because cache behavior varies over time.

Analyzing the File System Cache Data

You can use the data you collect with PerfMon to evaluate whether your server has enough memory to support an effective File System Cache.

To evaluate server memory

Determine how the size of your server's File System Cache varies over time.
Determine the extent to which cache performance varies with cache size.
Verify that the server has enough memory to support an effective cache even when the server is most active.

The following sections provide information to help you perform this evaluation.

Analyzing Cache Size Data

The Cache Manager in Windows 2000 adjusts the size of the File System Cache based on whether a computer is a workstation or a server, the amount of physical memory in the computer, and the applications and services the computer is supporting. In general, it is counterproductive to override the Cache Manager and manipulate the cache size directly. If the cache is too small to be effective, it is better to increase the amount of physical memory in the computer, or to redistribute memory-intensive applications to other servers.

Use the Memory\ Cache Bytes counter to monitor the size of the File System Cache. Task Manager also displays the size of the File System Cache in the File Cache field under Physical Memory on the Performance tab. A log of cache size reveals how the size of the File System Cache changes over time. Compare this data to a measure of general memory availability, such as data from the Memory\ Available Bytes counter. In general, when memory is scarce the system trims the cache, and when memory is ample the system enlarges the cache.

Note the points in the log when the cache is smallest. Keep track of how small the cache gets, and how often that happens. Also, note how much system memory is available when the cache size is reduced. This data is useful when associating the size of the cache with its performance. (To put this another way, if performance degrades when the cache is large, you should consider adding RAM. If performance degrades when the cache is small, you should consider leaving objects in the cache longer before you allow them to be flushed.)

Analyzing Cache Performance Data

Use the logged counter data to evaluate the performance of the File System Cache on your server. A hit is recorded when requested files are found in the cache. A miss or fault is recorded when requested files are not found. Misses and faults indicate how often the system needs to do extra work to retrieve files from somewhere other than the cache.

To evaluate the performance of your server's File System Cache, examine a log of Cache\ MDL Read Hits %. The higher the value, the better the File System Cache is performing. Values near 100 percent are not uncommon on IIS 5.0 servers with ample memory. Subtract the percentage of hits from 100 to determine the percentage of misses. Misses on MDL Reads usually require disk operations to find the requested data.

MDL Reads are the most common type of read used for retrieving many contiguous pages. Typically, MDL Reads are also the most common read operation on servers running IIS 5.0. To determine which type of cache read is most common on your server, use PerfMon to report the rates of different types of cache reads. Include Cache\ Copy Reads/sec, Cache\ Data Maps/sec, Cache\ Fast Reads/sec, Cache\ MDL Reads/sec, and Cache\ Pin Reads/sec.

You can also use the Memory\ Cache Faults/sec counter to indicate how often data sought in the File System Cache is not found there. This value should be as small as possible. The Memory\ Page Faults/sec and Memory\ Page Reads/sec counters are included to help you relate the fault rate of the cache to the fault rate in the system as a whole. Memory\ Cache Faults/sec is a component of Memory\ Page Faults/sec. The ratio of Memory\ Cache Faults/sec to Memory\ Page Faults/sec indicates the proportion of faults occurring in the cache, as opposed to the working sets of processes.

A high rate of cache faults can indicate a memory shortage. But it can also indicate that the organization of data on disk is inefficient. If the files used in sequence are stored on the same logical partitions of the same disk, they are more likely to benefit from the optimizing strategies of Cache Manager within Windows 2000, such as read aheads. The Memory\ Read Aheads/sec counter displays the rate of sequential reading from the cache.

Comparing Cache Size and Performance Data

To determine the extent to which the performance of the File System Cache correlates with the size of the cache, compare the size of the cache over time to the rate at which data sought in the cache is found there. Use the Memory\ Cache Bytes counter as an indicator of the size of the cache. Use Memory\ Cache Faults/sec as an indicator of the rate of cache misses, and Cache\ MDL Read Hits % as an indicator of the rate of cache hits.

If Memory\ Cache Faults/sec increases and Cache\ MDL Read Hits % decreases when the system has reduced the size of the File System Cache, the cache might be too small to really benefit the server. A less effective File System Cache is likely to degrade the performance of an IIS 5.0 server significantly, especially if the size of the cache is often reduced because of a general memory shortage.

If cache performance is poor when the cache is small, use the data you have collected to infer why the system reduced the cache size. Note the available memory on the server, and the processes and services running on the server, including the number of simultaneous connections being supported.

When you add physical memory to your server, the system allocates more space to the File System Cache. A larger cache is almost always more efficient, but typically it's a case of diminishing returns–each additional megabyte of memory adds less efficiency than the previous one. You must decide where the trade-off point is: the point at which adding more memory gets you so little improvement in performance that it ceases to be worthwhile.

In addition, defragmenting your disks makes it more likely for related pages to be copied into the cache together. This, in turn, improves the hit rate of the cache. Finally, consider reducing the workload on the server by moving some of the load to another server. For more information, see "Administering an ISP Installation" in this book.

Suggestions for Optimizing Memory Usage

Servers running IIS 5.0, like other high-performance file servers, benefit from ample physical memory. Generally, the more memory you add, the more the servers use and the better they perform. IIS 5.0 requires a minimum of 64 MB of memory; at least 128 MB is recommended. If you are running memory-intensive applications, your server could require a much larger amount of memory to run optimally (for example, most of the servers that service the microsoft.com Web site have at least 512 MB of memory).

Adding RAM to your system is not the only option, however. Here are a few suggestions for optimizing memory performance without adding memory:

Improve Data Organization Keep related Web files on the same logical partitions of a disk. Keeping files together improves the performance of the File System Cache. Also, defragment your disks. Even well-organized files take more time to retrieve if they are fragmented.
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 may help.
Replace or Convert CGI Applications CGI applications use much more processor time and memory space than equivalent ASP or ISAPI applications. For more information about ASP, ISAPI, and CGI applications, see "Web Applications" in this chapter.
Enlarge Paging Files Add paging files and increase the size of the ones you have. The Windows 2000 operating system creates one paging file on the system disk, but you can also create a new paging file on each logical partition of each disk.
Retime the IIS Object Cache Consider lengthening the period that an unused object can remain in the cache (use the ObjectCacheTTL setting in the registry, as mentioned earlier in this chapter, to accomplish this).

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
Change the Balance of the File System Cache to the IIS 5.0 Working Set By default, servers running the Windows 2000 operating system are configured to give preference to the File System Cache over the working sets of processes when allocating memory space. Although IIS 5.0–based servers benefit from a large File System Cache, the setting Maximize Throughput for File Sharing often causes the IIS 5.0 pageable code to be written to disk, which results in lengthy processing delays. To avoid these processing delays, set Server properties to the Maximize data throughput for network applications option.

To change Server properties
1. On the desktop, open My Computer and select Network and Dial-up Connections.
2. Right-click Local Area Connection and open its property sheet.
3. Select File and Printer Sharingfor Microsoft Networks and select Properties.
4. On the Server Optimization property sheet, select Maximize data throughput for network applications.
Limit Connections If your server doesn't 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 the system uses to keep track of connections.

To control the number of current connections
1. In the IIS snap-in, right-click a site, then choose Properties and select the Web Site tab.
2. Select the Limited To check box in the Connections panel. Type into the field the maximum number of connections you want to allow.
Eliminate Unnecessary Features You can also disable the performance boost for applications in the foreground. In addition, at times when you are not actively checking performance, you can disable performance-related logging in order to squeeze a bit more performance from your server.

Preventing Processor Bottlenecks

Servers running IIS 5.0 rely on the speed and efficiency of their processors. The IIS 5.0 code is multithreaded for efficient scaling on single-processor and multiprocessor computers, and is largely self-tuning. Nonetheless, processor bottlenecks are a potential problem on very active servers.

A processor bottleneck occurs when one or more processes take up nearly all the time of all processors on the computer. In a bottleneck, process threads ready to be executed must wait in a queue for processor time. All other activity comes to a halt until the queue is cleared. 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 the problem is not centered in the other components (such as memory, disks, or network connections), upgrading or adding to those components does not overcome this performance problem, and can make it even worse.

Monitoring Server Processors

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

There are several tools you can use to monitor processor performance. Web Capacity Analysis Tool (WCAT) and the Web Application Stress Tool are stress-testing tools that are both available on the Resource Kit companion CD. In addition, Task Manager, PerfLog, and PerfMon are commonly used to monitor Windows 2000–based servers. 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.

Using PerfMon to Monitor Processor Activity

To monitor your server's processors, use PerfMon to log data from the counters listed in Table 5.4:

Table 5.4 Counters for Processor Activity Monitoring

Counter	Indicates
System\ Processor Queue Length	Threads waiting for processor time. If this value exceeds 2 for a sustained period of time, the processor may be bottlenecked.
Processor\ % Processor Time (Total instance)	The sum of processor use on each processor.
Processor\ % Processor Time	Processor use on each processor (#0, #1, and so on). In a multiprocessor server, this counter reveals unequal distribution of processor load.
Processor\ % Privileged Time	Proportion of the processor's time spent in privileged mode. In the Windows 2000 operating system, only privileged mode code has direct access to hardware and to all memory in the system. The Windows 2000 Executive runs in privileged mode. Application threads can be switched to privileged mode to run operating system services.
Processor\ % User Time	Proportion of the processor's time spent in user mode. User mode is the processor mode in which applications like IIS 5.0 services run.
Process\ % Processor Time	The processor use attributable to each processor, either for a particular process or for the total for all processes. (These are shown in the list of instances.)

False Indications

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 should monitor the memory in your server. For more information about monitoring memory, see "Memory" in this chapter.

Analyzing Processor Activity Data

Of the counters listed in Table 5.4, 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 a PerfMon alert to notify administrators when the processor queue length reaches an unacceptable value.

The Processor\ % Processor Time counter is most often used as a general measure of processor activity on both single-processor and multiprocessor computers. System\ % Total Processor Time is included for monitoring system-wide processor use on multiprocessor computers. On single-processor computers, System\ % Total Processor Time always equals Processor\ % Processor Time. On multiprocessor computers, System\ % Total Processor Time represents the active time of all processors divided by the number of processors.

If the server workload is shared equally among all processors, System\ % Total Processor time is an excellent measure of processor activity. However, this counter hides bottlenecks resulting from unequal processor loads. (If one processor is 100 percent busy and three other processors are idle, the % Total Processor Time is 25 percent.)

Windows 2000 Server 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. For detailed processor monitoring, you need to chart Processor\ % Processor Time for each processor on the computer.

It's not unusual to encounter the following challenges in analyzing processor data:

A large processor queue when all processors are busy. Create a histogram of Process\ % Processor Time for each process. To do this, click the ViewHistogram button on the toolbar in PerfMon. The histogram shows the processor time consumed by each process.
A single bar in the histogram rises above all of the others. The process represented by the bar may 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.
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 "Web Applications" in this chapter.

Process Throttling

Process throttling limits the CPU usage of out-of-process applications and CGI applications on a per-site basis. The allowed amount is a percentage of the total CPU usage during a given interval, which defaults to one day.

There are four actions that can be taken when a limit is exceeded:

The lowest level action, engaged whenever a limited site exceeds its allocation at all, is that IIS 5.0 logs the error.
The second level action, engaged when the site exceeds 150 percent of its allocation, is that all out-of-process applications on the site have their CPU priority set to idle.
The next-to-highest level action, engaged when the site exceeds 200 percent of its allocation, is that IIS 5.0 halts all processes on the site that are affected by throttling, such as all CGI applications and out-of-process applications. These must then be restarted.
The highest level action is accessible only through the CPULimitPause property of the metabase. When this level is triggered, IIS 5.0 pauses the entire site and causes the server to issue a custom error message when any client attempts to connect to that site. (See the IIS 5.0 online product documentation for more information about this and other metabase settings.)

Process throttling also limits CGI processes to a certain amount of CPU usage. If your server performs CGI processing, you should probably lower the CGI timeout interval. For more information, see the IIS 5.0 online product documentation for more information. If you support a large number of long-running CGI applications, see "A Thread-Related CGI Program Issue" in this chapter.

Monitoring Connections

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

The next few sections discuss why connections have performance overhead, how you can use PerfMon and other tools to measure the overhead, and how to interpret the data you gather.

Performance Overhead of Connections

Each connection that an IIS 5.0 service establishes consumes some processor time. The network adapter card 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 on the connection and, when the connection is closed, processing is required to delete the structures that serviced the connection. Each time a connection is established, the load on the server increases.

One aspect of connection overhead is the time it takes to search the TCB table. TCP creates and maintains TCBs to store information about connections. This information can include, for example, data about the precedence of the connection, and its local and remote socket numbers. For efficient control, the TCBs are kept in a hash table, which is stored in the operating system's nonpaged memory pool.

IIS 5.0 includes several features to optimize its handling of connections. Among these features are HTTP Keep-Alives, which are different from and independent of Transmission Control Protocol/Internet Protocol (TCP/IP) Keep-Alives. While the latter are messages sent to determine whether an idle connection is still active, the former maintain a connection even after the connection's initial request is complete. The HTTP Keep-Alives feature keeps the connection active and available for subsequent requests. HTTP KeepAlives, which both the client and the server must support, are implemented to avoid the substantial cost of establishing and terminating connections. They are supported by IIS version 1.0 and later, Microsoft® Internet Explorer version 2.0 and later, and Netscape Navigator version 2.0 and later.

HTTP Keep-Alives are enabled in IIS 5.0 by default. Although they significantly improve bandwidth performance on most servers and improve the response times for clients, you can modify or eliminate them if they are not needed. You can also measure their effect on the performance of your system. To test their effect on the server, you can disable them, but it is recommended that you re-enable them when the test is concluded, to maintain the performance of the server.

Use the IIS snap-in to enable or disable HTTP Keep-Alives. You'll find this setting on the WebSite tab of the property sheets for the Web site.

Tip When you use Microsoft Management Console (MMC), right-click to get the properties of an item in a listing.

Using the IIS 5.0 Log to Monitor Connections

You can use IIS 5.0 logging to monitor the number of connections your server makes and to track patterns of client demand for your server. For more information about configuring and interpreting IIS 5.0 logs, see the IIS 5.0 online product documentation.

Using PerfMon to Monitor Connections

Table 5.5 lists the counters that you use with PerfMon to monitor connections to IIS 5.0.

Table 5.5 Performance Counters for IIS 5.0 Service Connections

Counter	Indicates
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 largest number of connections maintained simultaneously since the server was started

Because these counters display the last value they observe, and not an average, you must log their values over time to collect reliable data.

Also, these counters can exaggerate the number of simultaneous connections. This is because, at any given moment, some entries may not have been deleted, even though their connections have been closed.

Analyzing Connection Data

By monitoring the number of connections, you can identify patterns of client demand for your server. Divide your PerfMon logs into regular time intervals, and look at the number of connections served during each interval. Observe the length of the processor queue and the processor use 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 interval by:

A long, sustained processor queue (more than two threads).
High use rates on one or more processors.
A curve in the graph of the Current Connections counter on any IIS 5.0 service performance object that reaches a high value and then forms a plateau. This pattern often indicates that additional connections are being blocked or rejected.

To prevent processor bottlenecks, make certain that a lengthy processor queue isn't forming when you serve large numbers of connections. You can usually avoid a bottleneck during peak time by setting the connection limit to twice the average value of Current Connections. If the processor regularly becomes a bottleneck when servicing large numbers of connections, you might consider upgrading or adding processors, or limiting 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.

Note: The Active Server Pages, Web Service, FTP Service, and SMTP Server counters collect data at the Open Systems Interconnectivity (OSI) Application Layer. If any connections were blocked, rejected, or reset between the Transport and Application layers, counts of TCP/IP connections may not equal the sum of HTTP, FTP, and SMTP connections. For information about monitoring connections at lower layers, see "Network I/O" later in this chapter.

Monitoring Threads

IIS 5.0 runs in a set of multithreaded processes designed for efficient scaling on single-processor and multiprocessor systems. Threads are the sequences of execution in each process that run the process code on the processor. In the IIS 5.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.

The relationship between threads, connections, and requests is complex because IIS 5.0 uses the worker thread model, rather than the simpler, but less efficient, thread-per-client model. Instead of dedicating a thread to each connection or request, IIS 5.0 dedicates one pool of threads, the worker threads, to the task of 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:

Count the number of threads in the IIS 5.0 process.
Measure the amount of processor time each thread gets.
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 monitor or enumerate the threads in a process, including Process Monitor, Process Viewer, Process Explode, PerfLog, and PerfMon. Individual threads are difficult to monitor, especially if they frequently start and stop. Threads are also costly to measure. Be sure to monitor the overhead (by using Process: % Processor Time) of the process in which your tool runs, and subtract it from the data you collect.

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

Table 5.6 Counters for Monitoring IIS 5.0 Threads

Counter	Indicates
Process\ Thread Count: Inetinfo	The number of threads created by the process. This counter does not indicate which threads are busy and which are idle. This counter displays the last observed value, not an average.
Thread\ % Processor Time: Inetinfo => Thread #	How much processor time each thread of the Inetinfo process is using.
Thread\ Context Switches/sec: Inetinfo => Thread #	How many times the threads of the IIS 5.0 service are switched onto and off processor. This counter indicates the activity of IIS 5.0 service process threads.

Analyzing the IIS 5.0 Thread Data

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

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 context switch occurs each time a new thread runs, and each time one thread takes over from another. A large number of threads is likely to increase the number of context switches. While they allow multiple threads to share the processor, content switches also interrupt the processor and might interfere with its performance, especially on multiprocessor computers. As long as processor utilization is under 70 percent, however, this is not an issue.

Optimizing Thread Values

By default, the IIS 5.0 process creates up to four threads per processor. IIS 5.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 it. If the threads in the IIS 5.0 process appear to be overworked or underutilized, consider these tuning strategies:

If nearly all of the threads of the IIS 5.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, but do so cautiously. Unnecessary or underused processors will degrade performance, not improve it.
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 5.0 service process, use a registry editor to add the MaxPoolThreads entry to the registry. MaxPoolThreads does not appear in the registry unless it is added to the following:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Inetinfo \Parameters

MaxPoolThreads is calculated in units of threads-per-processor. Do not set this value below 2 or above 20. Continue monitoring the system carefully to make sure that changing the number of threads achieves the desired effect.

A Thread-Related CGI Program Issue

If your server simultaneously executes a large number of long-running CGI programs, they tie up the entire IIS 5.0 pool of I/O threads and the server hangs until one of the CGI programs finishes running, or crashes. There is a workaround that makes IIS 5.0 use a separate dedicated thread for each CGI application. To enable this workaround, create a DWORD value called UsePoolThreadForCGI in the following location, and set it to zero:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \W3SVC \Parameters

Suggestions for Improving Processor Usage and Performance

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 suggestions for optimizing thread values mentioned earlier in the chapter, consider doing the following:

Upgrade the L2 Cache When adding or upgrading processors, choose processors with a large secondary (L2) cache. File 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 5.0.
Improve DPC Handling Deferred Procedure Calls (DPCs) are similar to interrupts except that they have a lower Interrupt Request Level (IRQL). Unlike interrupts, DPCs can be delayed, allowing the processor to complete higher priority work. Platforms that distribute interrupts to all processors do not benefit from the Windows 2000 Server default DPC affinity. If you are administering a multiprocessor computer that distributes interrupts symmetrically, such as an Intel Pentium or Pentium Pro (P6) system for Windows 2000 Server, set the value of the ProcessorAffinityMask entry in the registry to zero. DPCs will be handled by the same processor that handled the interrupt from which the DPC evolved.

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
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 DPCs (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 Cards If you are adding or upgrading network adapters, choose those with drivers that support interrupt moderation. 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.
Limit Connections If you cannot upgrade or add processors, consider reducing the maximum number of connections that each IIS 5.0 service accepts. Limiting connections can result in connections being blocked or rejected, but it helps ensure that accepted connections are processed promptly.
Redesign the Web Site You can improve performance and reduce the processor workload by optimizing database use, optimizing the design of ASP pages, calling compiled components from scripts in ASP pages, using ISAPI instead of ASP (and ASP or ISAPI instead of CGI applications), substituting static Web pages for dynamic pages, eliminating the use of SSL except where it is necessary, moving trusted out-of-process applications into the Inetinfo process, and eliminating large bitmapped images or optimizing them to reduce their size. (For more information about optimizing scripts in ASP pages, see "ASP Best Practices" in this book.) It is also advisable to set long expirations on infrequently modified static files.
Adjust the Maximum Number of Threads IIS 5.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 may help to adjust the maximum number of threads in the Inetinfo process. 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.

Network I/O

The main purpose of most Web servers, obviously enough, is I/O. Requests come in, and pages go out. This requires a certain amount of bandwidth, and uses other server resources as well. In addition to IIS 5.0, of course, network I/O involves TCP/IP, which is handled by the system.

Network Bandwidth Requirements of a Server Running IIS 5.0

The speed of a connection to the Internet is governed largely by need and budget. Remember that the bandwidth available to clients has a large impact on the bandwidth required by an Internet server.

In intranet-only cases, the available bandwidth is limited by the network. If more bandwidth is needed, the network must be upgraded or, in the case of shared-resource networks (Ethernet, for example), it must be broken into subnets. Some servers have two or more network interfaces. This is the case, for example, if a Web server is connected to a database server via a private network. Different interfaces need not necessarily run at the same speed.

Monitoring the Network Connection

The primary functions of IIS 5.0 are to establish connections for its 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.

Bandwidth and Capacity

Bandwidth is measured in several different ways:

The rate at which bytes are transferred to and from the server.
The rate at which data packages are sent by the server. Data packages include frames, packets, segments, and datagrams.
The rate at which files are sent and received by the server.

Effective bandwidth varies widely depending 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.

Network capacity is measured, in part, by the number of connections established and maintained by the server.

Network Specifics (Data Transmission Rates, File Transfers, TCP Connections)

The simplest measure of the effective bandwidth of a server is the rate at which the server sends and receives data. PerfMon displays counts of data transmissions that are collected by many components of the server computer. The components that collect data each reside in different Open Systems Interconnectivity (OSI) layers:

Counters on the Web, FTP, and SMTP services performance objects measure data transmitted at the OSI Application Layer.
Counters on the TCP object measure data transmitted at the Transport Layer.
Counters on the IP object measure data at the Network Layer.
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 display different data. For example, the counters at the Application Layer count the bytes sent before the data is divided into packets and prefixed with protocol headers and control packets. Counters at the Application Layer measure data in this way because the data is in this form when the application sends it. Counters at the Application Layer do not include retransmitted data.

In addition, the counters display the data in units native to the component 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 "seven-layer" model, see "Additional Resources" at the end of this chapter.

Monitor Settings and Relevant Counters for Transmission Rates

The following tables list and describe some of the counters that can be used for measuring transmission rates. The counters in these tables display the transmission rate observed during the last sample interval. They do not display a rolling or cumulative average of the rate. Also, the counters that represent sums of other counters, such as IP\ Datagrams/sec, are simple sums of the other counters' values.

For more information about how counter values are calculated, check the counter type. A counter type determines how PerfMon calculates and displays that particular counter.

Table 5.7 lists and describes counters at the Application Layer.

Table 5.7 Counters for Measuring Transmission Rates at the Application Layer

Counter	Indicates
Web Service\ Bytes Sent/sec	The rate at which the HTTP server application is sending data, in bytes.
Web Service\ Bytes Received/sec	The rate at which the HTTP server application is receiving data, in bytes.
Web Service\ Bytes Total/sec	The rate at which the HTTP server application is sending and receiving data, in bytes; 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 server application is sending data, in bytes.
FTP Service\ Bytes Received/sec	The rate at which the FTP server application is receiving data, in bytes.
FTP Service\ Bytes Total/sec	The rate at which the FTP server application is sending and receiving data, in bytes; the sum of FTP Service\ Bytes Sent/sec and FTP Service\ Bytes Received/sec.
SMTP Service\ Bytes Sent/sec	The rate at which the SMTP server application is sending data, in bytes.
SMTP Service\ Bytes Received/sec	The rate at which the SMTP server application is receiving data, in bytes.
SMTP Service\ Bytes Total/sec	The rate at which the SMTP server application is sending and receiving data, in bytes; the sum of SMTP Service\ Bytes Sent/sec and SMTP Service\ Bytes Received/sec.

Table 5.8 lists and describes counters on the TCP object.

Table 5.8 Counters for Measuring Transmission Rates at the Transport Layer

Counter	Indicates
TCP\ Segments Sent/sec	The rate at which TCP segments are sent by using the TCP protocol.
TCP\ Segments Received/sec	The rate at which TCP segments are received by using the TCP protocol.
TCP\ Segments/sec	The sum of Segments Sent/sec and Segments Received/sec.
TCP\ Segments Retransmitted/sec	The rate at which segments are transmitted that contain one or more bytes TCP recognizes as having been transmitted before. Segments Retransmitted/sec is a proper 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 5.9 lists and describes counters on the IP object.

Table 5.9 Counters for Measuring Transmission Rates at the Network Layer

Counter	Indicates
IP\ Datagrams Sent/sec	The rate at which IP datagrams are sent by using the IP protocol. This counter does not include datagrams forwarded to another server.
IP\ Datagrams Received/sec	The rate at which IP datagrams are received from IP by using IP protocol. This counter does not include datagrams forwarded to another server.
IP\ Datagrams/sec	The sum of IP\ Datagrams Sent/sec and IP\ Datagrams Received/sec.
IP\ Datagrams Forwarded/sec	The rate at which IP datagrams are forwarded to their final destination by the server.

The sum of IP: Datagrams/sec and IP: Datagrams Forwarded/sec represents the rate at which all IP datagrams are handled by the server.

Table 5.10 lists and describes counters on the Network Interface performance object.

Table 5.10 Counters for Measuring Transmission Rates at the Data Link Layer

Counter	Indicates
Network Interface\ Bytes Sent/sec: Adapter#	The rate at which bytes are sent over each network adapter. The counted bytes include framing characters.
Network Interface\ Bytes Received/sec: Adapter#	The rate at which bytes are received over each network adapter. The counted bytes include framing characters.
Network Interface\ Bytes Total/sec: Adapter#	The sum of Network Interface\ Bytes Sent/sec and Network Interface\ Bytes Received/sec.

The Network Interface counters display data about the network adapters on the server computer. The first instance of the Network Interface object that you see in PerfMon represents the loopback. The loopback is a local path through the protocol driver and the network adapter. All other instances represent installed network adapters.

Analyzing the Data

The data provided by these counters is collected by different methods, is displayed in different units, and represents the view of different system objects. Some guidelines for interpreting the data follow:

The IIS 5.0 service counters display the number of bytes transmitted on behalf of each service that server provides. To calculate the total number of bytes sent or received by all IIS 5.0 services, sum the values for each service. You can determine the proportion of bytes transmitted by each service by computing the ratio of bytes for one service to the sum of bytes for all services, or for the network.
Data collected by the IIS 5.0 service counters underestimates the total number of bytes actually being transmitted to the network by the IIS 5.0 services. These values are collected at the Application Layer, so they measure data only. They do not measure protocol headers, control packets, or retransmitted bytes. In general, the bytes counted by the services represent approximately 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 your network is running at or near the total capacity of its communications link.
Counters on the TCP and IP performance objects display the rate at which data is sent and received on a TCP/IP connection at the Transport and Network layers, but they do not count 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 the bytes per segment can vary from 8 KB to 64 KB; the number of bytes per segment depends upon the size of the TCP/IP receive window and the maximum segment size negotiated when each connection is established.
Counters on 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. These values provide a relatively accurate estimate of the number of bytes transmitted over the network, but they do not measure the bytes transmitted by a specific IIS 5.0 service.

Despite the difficulty of comparing these counters to each other, they can all be related to other performance measures, such as the total number of connections served at a given bandwidth, or processor use at different throughput rates.

Counters and Settings for Monitoring File Transfers

Each successful request to IIS 5.0 results in the transfer of at least one file. Most static Web pages include multiple files, such as a file of text and one or more files of graphics. There are counters for each IIS 5.0 service, which display the number of files sent and received by the Web Service and the FTP service. The SMTP service is slightly more complex; its counters indicate messages sent and messages delivered, as well as messages received.

Table 5.11 lists and describes the file counters.

Table 5.11 Counters for Monitoring IIS 5.0 File Transfers

Counter	Indicates
Web Service\ Files Sent FTP Service\ Files Sent SMTP Service\ Messages Sent Total	The number of files or messages sent by the service since the service was started.
Web Service\ Files Received FTP Service\ Files Received SMTP Service\ Messages Received Total	The number of files or messages received by the service since the service was started.
Web Service\ Files Total FTP Service\ Files Total	The number of files sent and received by the service since the service was started. Files Total is the unweighted sum of Files Sent and Files Received. The SMTP service lacks this counter.

The file counters for a particular service can be used as indicators of the network activity of that service. They can also be associated with other performance measures to determine the effect of high and low rates of file activity on server components.

Note, however, that the file counters for an IIS 5.0 service display cumulative totals on all traffic since the service was started, regardless of when PerfMon was started. The counters do not display current values or the rate at which files are transmitted.

To calculate file transmission rates, you can use PerfLog to log the file counters. PerfLog automatically logs the time at which measurement is taken. After you have generated a log in PerfLog, you can enter the PerfLog output files into a spreadsheet that associates the time of the measurement and the file count, in order to derive the transmission rates.

Monitoring TCP Connections

If the bandwidth of your server is insufficient to handle its workload, it is likely that clients will be aware of it before the server is. Client requests to the server will be rejected or will time out, or the response will be delayed. On the server side, the indicators are less clear. The server will continue 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 it is not sufficient, the connections fail.

The counters on the TCP object 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 5.0 service. The counters on these objects display only successful connection requests. They do not display failed attempts to connect to these IIS 5.0 services. Like all counters at the Application Layer, they do not have information about connections until the connections are established. Performance counters that display the number of simultaneous connections maintained by IIS 5.0 are discussed in the section "Preventing Processor Bottlenecks" earlier in this chapter.

Table 5.12 lists and describes the counters that monitor the success and failure of connections to TCP.

Table 5.12 Counters for Monitoring TCP Connection Successes and Failures

Counter	Indicates
TCP\ Connections Established	The number of simultaneous connections supported by TCP (at last observation). This counter displays the number of connections last observed to be in the ESTABLISHED or CLOSE-WAIT state. It displays the last observed value only; its value is not an average.
TCP\ Connection Failures	The number of connections that have failed since the service was started (regardless of when PerfMon was started). TCP counts a connection as having failed when it goes directly from sending (SYNC-SENT) or receiving (SYNC-RCVD) to CLOSED or from receiving (SYNC-RCVD) to listening (LISTEN).
TCP\ Connections Reset	The number of connections reset since the service was started (regardless of when PerfMon was started). TCP counts a connection as having been reset when it goes directly from ESTABLISHED or CLOSE-WAIT to CLOSED.

You can also use the HTTP Monitoring Tool or a similar tool to monitor the functioning of the server. For more information about the HTTP Monitoring Tool, see "Tools" in this chapter.

Analyzing the Data

At the TCP level, you should monitor the TCP\ Connections Established counter regularly. If you notice a pattern in which the counter value often reaches, but rarely exceeds, a maximum (that is, the graphed line 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.

Failure to support current or increasing demand also might be evident from the number of connection failures and resets. The counters that monitor failures and resets show cumulative values, but you can set PerfMon alerts on the values or use PerfLog to log values over time. You can then use a spreadsheet to calculate the rates at which connections are rejected and reset. An increasing number of failures and resets or a consistently increasing rate of failures and resets can indicate a bandwidth shortage.

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. Many browsers try to minimize connection overhead by routinely closing connections by sending a TCP reset (RST) packet, rather than by closing the connection 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 close them abruptly.

Using the Network Monitor Program to Monitor Bandwidth

Network Monitor (NetMon) is a tool you can use to monitor data sent and received by the local computer. NetMon can:

Capture or trace data, and filter it based on different attributes.
Monitor throughput based on bytes or frames.
Monitor bandwidth based on the percentage of the network used.
Monitor errors, a possible consequence of an overloaded network.

Windows 2000 Server and Advanced Server include NetMon as an optional tool. For more information about NetMon, see the Windows 2000 Server product documentation.

For an overall view of bandwidth, use the Network Monitor Frames Per Second and Bytes Per Second status bars. Use the % Network Utilization status bar to view monitor network capacity used. The # Frames Dropped field indicates the number of frames that are not processed because the buffers on the network adapters are full. Frames are dropped when the processor cannot handle the traffic generated by the network.

Limiting Bandwidth for Static Files

If the bandwidth on your server is not sufficient to handle the load imposed by IIS 5.0, you can limit the amount of bandwidth IIS 5.0 uses for static HTML pages (files with .htm or .html extensions). This setting affects all services that route directly through IIS 5.0, but not those that are sent to other engines or applications (ASP, ISAPI, CGI, and SQL Server, for example).

Remember that per-instance bandwidth throttling is not supported for FTP service.

To enable bandwidth throttling

In the IIS snap-in, right-click a Web site, then click Properties and select the Performance tab.
Select the Enable Bandwidth Throttling check box. In the Maximum network use box, type the maximum amount of bandwidth you want IIS 5.0 to use for static HTML pages, in kilobytes per second.

You do not need to restart the server or the service to activate bandwidth throttling; it is enabled dynamically.

Monitoring Bandwidth Throttling

When you enable bandwidth throttling, IIS 5.0 activates a set of counters to monitor it. You can identify these counters by the presence of the phrase "Async I/O" in the counter name. These counters are active only when bandwidth throttling is enabled. (If bandwidth throttling is not enabled, the counters appear in PerfMon, but they always have a value of zero.)

The Async I/O counters are part of the IIS 5.0 Global performance object. They represent totals for all of the IIS 5.0 services. Bandwidth is not measured for each service. Table 5.13 lists and describes the Async I/O counters.

Table 5.13 Counters for Monitoring Bandwidth Throttling

Counter	Indicates
Internet Information Services Global\ Current Blocked Async I/O Requests	The number of requests blocked (that is, held in a buffer until bandwidth is available) by bandwidth throttling as reported during the most recent observation
Internet Information Services Global\ Total Allowed Async I/O Requests	The number of requests allowed by bandwidth throttling since the service was last started
Internet Information Services Global\ Total Blocked Async I/O Requests	The number of requests blocked (that is, held in a buffer until bandwidth is available) by bandwidth throttling since the service was last started
Internet Information Services Global\ Total Rejected Async I/O Requests	The number of requests rejected by bandwidth throttling since the service was last started
Internet Information Services Global\ Measured Async I/O Bandwidth Usage/	The number of bytes sent asynchronously, averaged over a one-minute period, as indicated by a sample taken by bandwidth throttling

Analyzing the Data

The bandwidth setting determines whether IIS 5.0 accepts or rejects a request for a static HTML page, based on periodic samples of the rate at which bytes are sent on the server.

If the amount of bandwidth used (as indicated by the sample) approaches the maximum set by the user, bandwidth throttling blocks read requests, but allows write requests and transmission requests. Read requests are blocked first because they are likely to result in further requests.
If the amount of bandwidth used exceeds the maximum set by the user, bandwidth throttling rejects read requests, blocks large write requests and transmission requests, and allows small write requests and transmission requests.

To determine how many requests are being blocked and rejected, monitor the Async I/O counters. These counters display cumulative totals, so it's best to use PerfLog to log the counter values. Alternatively, you can use a spreadsheet to calculate the rate over time. You can also set a PerfMon alert to notify administrators when the number of blocked or rejected requests exceeds a threshold.

No rule exists that sets a threshold or appropriate number of blocked and rejected requests. Tolerance for client delays and rejections is a business rule, not a performance measure. However, you can use the Async I/O counters to enforce your business standards, at least for static HTML pages.

Optimizing the Network Connection

If the bandwidth on your server is not sufficient to support demand, you can solve the problem by increasing 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 2000 registry or the IIS 5.0 metabase.

It is frequently possible to reduce your use of bandwidth by optimizing Web application scripts or content. This option is well worth looking into as an interim solution, partly because it can also improve response time and hence the user experience; but if your client base is growing, you will eventually have to increase the bandwidth of your network connection anyway. For more information about scripted Web applications, see "ASP Best Practices" in this book.

Lengthening Connection Queues

You can sometimes effectively increase existing bandwidth by increasing the length of the connection queues. Requests for connections to IIS 5.0 services are held in queues until the service is available to respond to the request. A separate queue exists for each of the IIS 5.0 services, but all queues have the same maximum size. By default, each queue can hold up to 15 connection requests. If the queue to a service is full, any new connection requests are rejected.

The default queue length of 15 connection requests is sufficient for most servers. However, if your server is rejecting many requests when the services are most active, you can increase the maximum number of items in the queue. If you change the queue length, be sure to monitor server processor use, server memory use, and the connection counters to avoid creating a system bottleneck.

To change the maximum number of connection requests in the queue for each IIS 5.0 service, add the ListenBackLog key to the registry. Set the value of ListenBackLog to the maximum number of connection requests you want the server to maintain. You must place Listen_Back_Log in the registry at:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Inetinfo \Parameters

Using HTTP Keep-Alives

To ensure optimal bandwidth, you can also verify that HTTP Keep-Alives are enabled. HTTP Keep-Alives maintain a connection even after the initial request is complete. HTTP Keep-Alives are enabled by default, but can be disabled. To disable them, right-click a site in the Internet Services Manager, then click Properties; select the Performance tab and clear the HTTP Keep-Alives Enabled check box.

Disk I/O

IIS 5.0 writes its logs to disk, so there is almost always some activity, even when clients are hitting the cache 100 percent of the time. Under ordinary circumstances, disk activity, other than that generated by logging, serves as an indicator of issues in other areas. For example, if your server needs more RAM, you'll see lots of disk activity because there are lots of hard page faults. But there will also be lots of disk activity if your server houses a database or your users request many different pages.

Monitor Settings and Relevant Counters

Typically you use the Physical Disk counters to watch for spikes in the number of disk reads when the server is busy. If you have enough RAM, most connections will result in cache hits unless, of course, you have a database on the same server and clients are making dissimilar queries, which precludes caching.

If you don't have anything that is obviously disk-intensive on your server, but you see lots of disk activity anyway, you should check RAM use immediately, to make sure you have enough memory.

Monitoring a Remote Computer

When you are monitoring a server remotely, the Internet Information Services Global, Active Server Pages, Web Service, FTP Service, and SMTP Service performance objects and counters appear in PerfMon only when the related IIS 5.0 service is running on the computer being monitored. If you do not see these objects in the Add to Chart dialog box, close PerfMon on your computer, start the IIS 5.0 service on the computer being monitored, and then start PerfMon again.

If the objects and counters still do not appear in the Add to Chart dialog box, or if they appear intermittently, make certain that no one else is using PerfMon to monitor the remote computer. All remote users must restart PerfMon after the IIS 5.0 service is started, or none of them will see the IIS 5.0 counters. Also, check the Event Viewer application event log for errors. Errors in the service or in loading the counters can also prevent PerfMon from displaying the counters. (Errors are logged on the main machine, not on the remote machine.)

Web Applications

Web applications can be written haphazardly, in which case they may work but will be inefficient (for example, a haphazardly-written script may make many separate references to a database instead of a single comprehensive one). On the other hand, Web applications can be constructed with an eye toward speed and efficiency. In addition, a server can be configured to run Web applications better, or to serve static content better. For most applications that are not well adapted to the use of static pages, using scripts in ASP pages to call server-side components offers performance close to that of ISAPI, with the advantage of more rapid development time than with ISAPI. For more information about Web application development strategy, see "Developing Web Applications" and "ASP Best Practices" in this book.

If Web applications are an important part of your site, the performance of those applications is critical in determining the site's capacity. Testing is the only way to find out the capacity and performance of a Web application. WCAT and the Web Application Stress Tool, which are included on the Resource Kit companion CD, are useful stresstesting tools. ("Additional Resources" at the end of this chapter includes a source for more information about the Web Application Stress Tool.)

Before you write an application, however, it's useful to have a general sense of the performance capabilities of different Web application types. In IIS 5.0, ISAPI applications running as DLLs in the IIS 5.0 process generally offer the best performance. Next come ASP pages, followed by CGI applications.

Tuning the ASP Queue and Thread Pool

There have been significant changes in the handling of ASP queuing and related caching issues in IIS 5.0 relative to IIS 4.0:

In IIS 4.0, the IIS Template Cache limit was set to -1 (that is, unlimited). In IIS 5.0 it is set to 256 files. You can, and almost certainly should, adjust this to suit your Web site's requirements, but do not set it to zero. For an explanation, see the next section, "How This Affects Server Administration."
In IIS 4.0, the IIS Script Engine Cache limit was set to 30 files. In IIS 5.0 it is set to 120. As with the IIS Template Cache, you can change this limit.
In IIS 4.0, ProcessorThreadMax was in the registry, and was set to 10. Administrators routinely changed this value themselves as needed. In IIS 5.0, the setting has been moved to the metabase, is set to 25, and is handled automatically.
In IIS 4.0, the Request Queue length was set to 500 by default. In IIS 5.0, it is set to 3,000. You probably won't need to change this setting, but you can if you need to. In addition, you can use Custom Errors. There is also automatic client-connection testing so that an ASP page is processed and the output sent only if the client is still connected. (Unfortunately, many proxy servers keep the connection alive even if the client cancels it, defeating the purpose of this test.)

How This Affects Server Administration

With the IIS Template Cache limit set to -1, as it was in IIS 4.0, this cache could grow arbitrarily large. On Web sites with lots of ASP content, the IIS Template Cache tended to fill all of the RAM in the server. In contrast, this limit in IIS 5.0 is set by default to 256 files. Because each site has its own requirements, you should reset the limit to meet your site's particular needs.

Perhaps the easiest way to accomplish this is to monitor performance as you increase and decrease the value. Because an entry in this cache can point to one or more entries in the IIS Script Engine Cache, and because best performance occurs if the scripts in ASP pages are found in the IIS Script Engine Cache, you should never set the limit on the IIS Template Cache to zero. (Doing so prevents any hits on the IIS Script Engine Cache, because the IIS Script Engine Cache entry for a particular *.*asp file can only be referenced through its template. Thus, if the template for it is not cached, by definition, the IIS Script Engine Cache is rendered useless.) IIS Script Engine Cache hits provide better performance than hits on the IIS Template Cache, so if you make IIS Script Engine Cache hits impossible, performance suffers badly unless all your pages are static.

To monitor the IIS Template and Script Engine Caches, use the following counters in PerfMon: Active Server Pages: Templates Cached, Active Server Pages: Template Cache Hit Rate, and Active Server Pages: Script Engines Cached.

IIS 5.0 includes a mechanism that effectively adjusts the value of the ASPProcessorThreadMax metabase entry "on the fly" (the actual value is not changed). When processor utilization drops below 50 percent, which indicates that threads are blocked (perhaps while waiting for an external database to return the results of a query), IIS 5.0 increases the number of active threads so that other requests can be serviced in a timely manner. When processor utilization exceeds 80 percent, indicating a relatively unblocked situation, IIS 5.0 deactivates threads to reduce the amount of context switching. Both lower and upper bounds are settable; 50 percent and 80 percent are the default values.

You can still change the length of the ASP Request Queue if you need to, and you can use Custom Errors to return friendly messages if your server becomes too busy to handle all current requests. Remember that a custom "Server Too Busy" error message is returned only when the length of the queue is at its maximum and another request comes in. (For information about creating custom error messages, see the IIS 5.0 online product documentation.)

In sum, a lot of the tweaking that was necessary in IIS 4.0 is performed automatically in IIS 5.0, thus reducing the workload on server administrators. But administrators can still change settings to accommodate specific conditions they encounter on their servers.

Optimizing for Web Applications

Web applications have much higher overhead than static HTML pages. But this should not deter you from using them. By monitoring applications and estimating their overhead during periods of varying activity, you can make sure your server is prepared for the increased workload.

Here are some suggestions for optimizing your configuration for Web applications:

Upgrade ProcessorsWeb applications benefit from faster processors.
Add Processors Components called by ASP can (and should) be multithreaded, which means they can run simultaneously on multiple processors; adding a second processor to a single-processor system brings the most benefit. Even if the expense is not prohibitive, you shouldn't use more than four processors per system at this time.
Add Memory Adding memory may help if applications are running within their own processes. (By default, ASP and ISAPI applications run within the IIS 5.0 process, but you can choose to run them within their own memory spaces.)
Defragment Your Disks If your cache performance declines over time, defragment the disk(s). Your files may have become fragmented over time.
Redesign Your Static Pages Running Web applications takes more time than serving static pages. If you are generating pages dynamically to satisfy user preferences, consider substituting as many as 10 or 20 different static variations for a single dynamically-generated page. If you are generating pages dynamically to provide frequently-updated data, consider redesigning your application so that it generates a single dynamic page on a fixed schedule and then stores that page for retrieval until the next update.
Convert CGI Scripts to Scripts in ASP Pages or to ISAPI Applications Scripts in ASP pages and ISAPI applications are optimized to run on Windows 2000. CGI applications are much less efficient, because each invocation spawns an entire process. For more information about converting CGI scripts, see "Migrating a Web Server to IIS 5.0" in this book.
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 by a considerable margin.

Web applications are continuing 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 using them.

Short-Term Problems and Temporary Fixes

If you expect a large spike in traffic on a particular page or set of pages, you can always change that page or set it to static HTML for a few days. This may involve some redesign, but the effort may prove worthwhile. When many thousands of people traverse three or four scripted pages to get to a particular download page during a short period, for example, your server is using a lot more resources than it really needs to. You could, instead, provide a static front page with simple navigation, on a temporary basis, and save yourself and your users a lot of headaches.

Tuning Tips

Here are some general tips for maintaining or improving performance.

This may seem obvious, but sometimes people do forget: Make sure debugging for ASP is turned off.
Set Expires for all images and for HTML wherever possible. Proxy servers and browsers will make fewer calls to the Web server as a result.
Remove Microsoft® Visual Basic® objects from ASP Session state if they are Apartment threaded (not Java or most C++ objects, though).
Cache output from ASP if possible; if not, cache inputs to ASP if possible.
If you have a large installation with many Web sites, each attached to a different IP port, your server may create too many backlog monitor threads (the system creates a thread for every 64 Web sites). The workaround for this is to disable the backlog monitor. To disable the backlog monitor, set the following registry key to 1:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Inetinfo \Parameters \DisableBacklogMonitor

Then restart the FTP and Web services.

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Monitoring Security Overhead

Security is achieved only at some cost in performance. Measuring the performance overhead of a security strategy is not simply a matter of monitoring a separate process or threads. The features of the Windows 2000 security model and other IIS 5.0 security services run in the context of the IIS 5.0 process; they are integrated into several different operating system services. You cannot monitor security features separately from other aspects of the services.

Instead, the most common way to measure security overhead is to run tests comparing server performance with and without a security feature. The tests should be run with fixed workloads and a fixed server configuration, so that the security feature is the only variable. During the tests, you probably want to measure:

Processor Activity and the Processor Queue Authentication, IP address checking, SSL protocol, and encryption schemes are security features that require significant processing. You are likely to see increased processor activity, both in privileged and user mode, and an increase in the rate of context switches and interrupts. If the processors in the server are not sufficient to handle the increased load, queues are likely to develop. Custom hardware may help here. For more information, see "Security" in this book.
Physical Memory Used Security requires that the system store and retrieve more user information. Also, the SSL protocol uses long keys–40 bits to 1,024 bits long–for encrypting and decrypting the messages.
Network Traffic You are also likely to see an increase in traffic between the IIS 5.0–based server and the domain controller used for authenticating logon passwords and verifying IP addresses.
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 lots of processor cycles. Downloading files from servers using the SSL protocol can be 10 to 100 times slower than from servers that are not using SSL.

If a server is used both for running IIS 5.0 and as a domain controller, the proportion of processor use, memory, and network and disk activity consumed by domain services is likely to increase the load on these resources significantly. The increased activity can be enough to prevent IIS 5.0 services from running efficiently. It is a good idea to test such a server thoroughly before deploying it.

Measuring Security Overhead with WCAT

WCAT is a script-driven, command line – based application that tests your server configuration using a variety of predetermined, unvarying workloads. You can use WCAT to test how your server responds to different workloads or test the same workload on varying configurations of the server.

WCAT includes a folder of prepared test workloads; alternatively, you can use it to create your own workloads. WCAT also includes a special option, ssl.testname, which adds SSL protocol settings to any workload test.

A WCAT test simulates clients and servers communicating over a network, and ordinarily requires at least three computers for each test:

At least one computer that simulates a client, which runs one or more virtual clients
One computer that acts as a server
One computer, called a controller, which initiates and monitors the test

Both client and controller can run on one computer. (In fact, all three functions can run on a single computer, but this produces skewed results.)

To produce a realistic test, it is best to associate four or more client computers, each running several virtual clients, with each server. The processors in the client computers should be at least as fast as the processors in the server computer. If they are not, more client computers should be associated with each server computer. WCAT works best if the network that connects the computers has little or no traffic that is not related to the test. It is preferable to use a link dedicated only to the test. A 100 Mbps or faster network is recommended.

Testing Security Features

To test a security feature, first run a WCAT test with the feature, then run the same test without it. It is important to run the "with feature" and "without feature" versions of the test on varying workloads. WCAT includes over 200 MB of prepared workloads ranging from 12 files to 1,600 files. You can create additional tests of workloads with 2,000 or more files.

WCAT has several options for collecting data on the tests:

You can use WCAT's own log of performance data. Open this log, which is a text file, with any word-processing program. The WCAT user guide explains how to interpret a WCAT log.
You can run IIS 5.0 logging in conjunction with WCAT to count the number of logons and file accesses.
You can collect performance counter data with WCAT. The WCAT run command includes a -p switch to do this. You can select counters by entering the names of counters in a script file. WCAT even includes a sample counter file, Server.pfc. (Monitoring performance counters adds only minimally to the load on the system.) When you use this option, WCAT logs the counter data in its usual report, and also outputs a performance log file in tab-separated form, so that you can import the logged counter data into a spreadsheet or data-processing software.

You should repeat each test several times and average the results to eliminate unintended variations of 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 security feature. You can use these results for planning configuration changes, in order to handle the security overhead.

WCAT is the primary tool used for determining security overhead. However, PerfMon also includes a set of counters you can use to monitor one specific aspect of security: authenticating users.

Using PerfMon to Track Anonymous and Nonanonymous Connections, and Not-Found Errors

The Web Service and FTP Service performance objects include counters that display the number of anonymous and nonanonymous connections to each of these IIS 5.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 the case with authentication.)

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

Combining data from these counters with general measures of server performance, such as data on processor time, the processor queue, memory, disk reads and writes, and throughput, is even more useful. Using the combined data, you can associate varying numbers and proportions of anonymous and nonanonymous users with their effect on the performance of system components.

The counters that display the numbers of anonymous and nonanonymous connections are called Current Anonymous Users and Current NonAnonymous Users. These counters, however, actually display connections, not users. Users who connect more than once are counted each time they connect. The Anonymous and Nonanonymous User counters display the number of anonymous and nonanonymous connections to the IIS 5.0 service when the values were last observed. They do not report averages or rates. These counters can exaggerate the number of connections, because closed connections may not yet have been deleted when the counter is displayed.

Table 5.14 lists the counters for anonymous and nonanonymous connections. These counters are part of the Web Service and FTP Service performance objects.

Table 5.14 Counters for Anonymous and Nonanonymous Connections

Counter	Indicates
Web Service\ Anonymous Users/sec Web Service\ NonAnonymous Users/sec	How many anonymous and nonanonymous users connect to the IIS 5.0 service each second. (These counters provide instantaneous values rather than averages.)
Web Service\ Current Anonymous Users FTP Service\ Current Anonymous Users Web Service\ Current NonAnonymous Users FTP Service\ Current NonAnonymous Users	How many anonymous and nonanonymous users are currently connected to the IIS 5.0 service.
Web Service\ Maximum Anonymous Users FTP Service\ Maximum Anonymous Users Web Service\ Maximum NonAnonymous Users FTP Service\ Maximum NonAnonymous Users	The maximum number of anonymous and nonanonymous users that have been connected simultaneously to the IIS 5.0 service since the service was last started.
Web Service\ Total Anonymous Users FTP Service\ Total Anonymous Users Web Service\ Total NonAnonymous Users FTP Service\ Total NonAnonymous Users	A running total of anonymous and nonanonymous connections to the IIS 5.0 service since the service was last started.

The Current Anonymous Users and Current NonAnonymous Users counters operate based on the following definitions:

The Anonymous User counters display the number of connections whose requests either did not contain a user name and password, or whose user name and password were ignored because authentication is not permitted on the server. If anonymous connections are not permitted on the server, the value of all anonymous user counters is always zero.
The NonanonymousUser counters display the number of connections whose requests contained a valid user name and password, or whatever authentication is required by a custom authentication scheme. If authentication is not enabled on the server, and none of the applications that run on the server request or require authentication, then the value of all nonanonymous user counters is always zero.

These counters count successful connections only. If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as nonanonymous.

Counting Not-Found Errors

The Web Service performance object includes a counter that displays not-found errors. Not-found errors are client requests that could not be satisfied because they included a reference to a Web page or a file that did not exist. (These errors are sometimes described by their HTTP status code number, which is 404.)

Many not-found errors occur because Web pages and files are deleted or moved to another location. However, some can result from user attempts to access documents that they are not authorized to have. (The code number of these "Access forbidden" errors is 403, and most browsers report them differently from 404 errors. They do not show up in the Not Found Errors/sec counter results.)

You can use the Web Service\ Not Found Errors/sec counter to track the rate at which notfound errors are occurring on your server. Alternatively, set a PerfMon alert to notify the Administrator when the rate of not-found errors exceeds a threshold.

Table 5.15 is a brief description of the Web Service\ Not Found Errors/sec counter.

Table 5.15 Counter for Not-Found Errors

Counter	Indicates
Web Service\ Not Found Errors/sec	The number of client read requests that could not be 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.

Analyzing the Data and Planning Upgrades

After you have collected data on the effect of adding security features to your server configuration, you can use the results to plan configuration changes. This new configuration will help you handle the additional workload required to support security features. The following approaches are recommended:

Upgrade or Add Processors Security features are often very processor-intensive. Once again, it should be noted that the SSL protocol consumes a significant amount of processor time. Because Windows 2000 security features are multithreaded, they can run simultaneously on multiple processors. Thus, adding processors improves performance significantly and prevents the processors from becoming a bottleneck.

For best results, choose processors with large (up to 2 MB) secondary (L2) cache space. When encrypting and decrypting data, the processor spends much of its time reading and writing small units of data to and from the main memory. If this data can be stored in the processor cache instead, the data can be retrieved much faster.
Add Memory If security features cause increased paging or shortages in virtual memory, adding more memory will help. The physical memory used to support the security service consumes space that could be used to cache files. To accommodate peak use, you should allow for twice as much memory as required during times of average use, while still maintaining 10 MB of available memory.
Use Custom Hardware Custom hardware can make a significant difference in the way your server handles security overhead. (Be sure to test any nonstandard hardware thoroughly, to be sure it is fully compatible with the other hardware and software you use.)

Do not, however, 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.

Tools

This section provides a description of the tools mentioned in this chapter. Some tools passively watch either the server or the network; others provide a way to actually probe and stress-test the server and its network connections. The following tools are provided with Windows 2000 Server, IIS 5.0, or the Resource Kit companion CD.

The System Monitor

The System Monitor, commonly referred to as PerfMon (Perfmon.msc), is a snap-in control for MMC. It reads software counters that are built into both IIS 5.0 and Windows 2000 Server. It also lets you log counter activity and set alerts. PerfMon is indispensable for watching your server. The startup PerfMon display is shown in Figure 5.1.

Bb742410.iischp5_iis0501(en-us,TechNet.10).gif

Figure 5.1 The PerfMon Snap-in

Performance Counters

Software performance counters are built into IIS 5.0 and the Windows 2000 operating system. Developers can also build them into custom ISAPI DLLs. These counters are frequently misrepresented as being "PerfMon Counters," but in fact they are built into IIS 5.0 and the operating system, not into PerfMon. These performance counters can be read directly by many applications, including PerfMon, the Web Application Stress Tool, and WCAT. PerfMon provides a handy user interface to performance counters, for the purposes of monitoring and logging.

Each performance counter is named by the object it collects data from (for example, the processor) and by the data it collects (for example, in the PhysicalDisk performance object, Current Disk Queue Length). The object and the specific counter name are separated by a backslash (\). If more than one instance of a particular counter exists, the instance name is separated from the counter name by a colon, and if more than one object or instance of a particular type exists (for example, if your server has more than one processor chip), a hash mark or number sign (#) and a number (the count of the specific object, starting at 0) are presented at the end of the counter or instance name (for example, Process\ % User Time: explorer#0). For some counters, "<No Instances>" is shown in grayed-out text in the list of instances, if there is no current instance.

For a description of a particular counter, click the + button in PerfMon, then select the counter you're interested in, and click the Explain button. Note that many of the IIS 5.0 counters display the last observed value or a cumulative count, not an average value or rate.

Different counters provide different kinds of information, at varying levels of granularity, so it's important to know which counters to watch. For example, there are both logical and physical Disk counters; the counters of the Processor object are replicated for each processor in the system, and so on. To choose a specific instance of a counter, use the list of instances on the right-hand side of the Add Counters dialog box, as shown in Figure 5.2. To reach this dialog box, click the + button in the toolbar on the right-hand side of the PerfMon console.

Bb742410.iischp5_iis0502(en-us,TechNet.10).gif

Figure 5.2 PerfMon Add Counters Dialog Box

PerfMon is not limited to the computer on which it is installed. Use the Select counters from computer field in the Add Counters dialog box to choose a different computer to read from. This is especially helpful when you don't want to add any more overhead to the operation of your server than is absolutely necessary. Remember that the service you want to monitor on the other computer must be running in order for its counters to be exposed. If the service is not running, you need to quit PerfMon, start the service, and run PerfMon again.

Performance Counter Check

Performance Counter Check, included on the Resource Kit companion CD, is a simple tool that allows you to read performance counters from within Microsoft® Windows® Script Host (WSH) or from within an ASP page. It is a scriptable COM object that reads one counter at a time. (To monitor more than one counter, make multiple instances of the object.)

The HTTP Monitoring Tool

The HTTP Monitoring Tool, included on the Resource Kit companion CD, monitors HTTP activity on your server and alerts you to dramatic changes in activity. If a supposedly active server stops serving pages, for example, it might have crashed and probably needs to be checked. The HTTP Monitoring Tool is composed of three main components:

Real-Time Sampling Service is a Windows 2000 Service that makes HTTP requests to ASP pages on live machines.
SQL Reporting Server uses FTP to retrieve sampling results, and loads this data into a SQL Server database that is used for reporting the results.
Client Monitor uses ASP pages displayed in a browser to show status information about site availability, based on the data stored in the SQL Reporting Server.

NetStat and NetMon

These two tools collect information about the network.

NetStat is a command that you issue from the command line. It detects current network connections and lists them with information about protocol, local address, foreign address and state. NetStat goes hand in hand with the Net Use command, which lists network connections to other servers. For a listing of options, type netstat /? or net use /? at the command-line prompt.

NetMon (the Network Monitor) is one of the Windows 2000 Administrative Tools. Use it to monitor network traffic. NetMon is not installed by default, but you can install it yourself from Control Panel.

To install NetMon

Open Add/Remove Programs and select Configure Windows.
Click the Components button to start the Windows 2000 Components Wizard.
Select Networking Options, click the Details button, and select Microsoft Network Monitoring Tools.

Process Viewer, Process Explode, Process Monitor, and Event Viewer

These tools (Pviewer.exe, Pview.exe, Pmon.exe, and Eventvwr.msc respectively) are provided with the Windows 2000 operating system, but only the Event Viewer is available from the Start menu as an Administrative Tool. (Use the Start menu to reach the others.)

Process Viewer lets you examine each process in detail, set its priority and thread priority, and even stop the process if necessary. It can also give you detailed information about memory usage. You can use Process Viewer to connect to other computers and to view their processes.

Process Explode examines processes on the local system only. It lets you view each process in considerable detail, set thread priority, view and change security settings, and even terminate applications if necessary.

Process Monitor, like Process Explode, examines processes on the local system only. It lets you view each process in some detail, but does not permit you to set parameters.

Event Viewer examines the system's event logs. For example, if one or more services fail to start when you bring up a server, you can use Event Viewer to begin your investigation of the problem.

Web Application Stress Tool and WCAT

Included on the Resource Kit companion CD, both of these tools are intended for stress testing, and are superficially equivalent. But you'll find that they differ in some areas, and you are likely to prefer one or the other for a particular testing task. Although WCAT will not be discussed in this section, both tools have documentation on the CD. The next section of this chapter also includes a tutorial on the Web Application Stress Tool.

Getting Started with the Web Application Stress Tool

The Web Application Stress Tool is designed to realistically simulate multiple browsers requesting pages from a Web site. You can use this tool to gather performance and stability information about your Web application. This tool simulates a large number of requests with a relatively small number of client machines. The goal is to create an environment that is as close to production as possible, so that you can find and eliminate problems in the Web application prior to deployment.

Installing the Web Application Stress Tool

For instructions on installing the Web Application Stress Tool, see the Resource Kit companion CD.

Using the Web Application Stress Tool Sample Script

When you run the Web Application Stress Tool for the first time, it creates a script named Sample Script. Use this script to get a feel for the main features in the Web Application Stress Tool. The actual Web pages used in the Sample Script are stored in the folder where you installed the Web Application Stress Tool. Copy the \samples folder to the root directory of your Web site before continuing with this tutorial.

Script View, Script Items, and Script Item Details View

The left-hand window of the Web Application Stress Tool is known as the Script view, which displays all of the scripts stored in the current Web Application Stress Tool database. If this is a new database, the only items you see in the Script view are Defaults and Sample Script.

There are seven script items in the Sample Script, each of which utilizes a special feature of the Web Application Stress Tool. For example, notice that one of the script items is a POST. Double-click the row header to the left of the POST script item and double-click. This opens the Script Item Details view, shown in Figure 5.3. Using this view, you can edit the query string name-value pairs, change POST data, modify the header, enable Remote Data Service (RDS), and enable SSL.

Bb742410.iischp5_iis0503(en-us,TechNet.10).gif

Figure 5.3 The Web Application Stress Tool Script Item Details View

Notice that the names User and Password on the Querystring tab are being passed in the query string. Also notice that %Username% and %Password% are the values being passed. These are not literal values; they are variables that tell the Web Application Stress Tool to pass the next available user and next available password from the list. The Web Application Stress Tool automatically cycles through the user names and passwords, passing the next set with each POST.

Close the Script Item Details view by clicking the OK button.

Page Groups

The last two script items in the Sample Script contain the text "adGrp" under the Group column. These are known as page groups. A page group is shown as "Default" unless you change it. The Web Application Stress Tool uses page groups to change the order in which it invokes the script items, and to change the number of times that it invokes each script item while a script runs.

Select the Page Groups node in the script tree view, shown in Figure 5.4, to see a list of all the page groups. You can also change the distribution percentages from this view. Notice that Keep-Alives are enabled for entire page groups at a time. For more information about page groups in the Web Application Stress Tool, see the Knowledge Base article at https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

Bb742410.iischp5_iis0504(en-us,TechNet.10).gif

Figure 5.4 The Web Application Stress Tool Page Groups Node

Performance Counters

Select the Perf Counters node from the script tree and click the Add Counter button. (The first time you click this button, the Web Application Stress Tool may take a few seconds to load the Add Counters dialog box.) Add the following counters:

Computername\ Web Service\ Get Requests/sec
Computername\ Web Service\ Post Requests/sec
Computername\ Processor\ % Processor Time\_total
Computername\ Active Server Pages\ Requests/sec

Change the Collection Interval, shown in Figure 5.5, to every 5 seconds. Capturing the correct performance monitor counters is central to obtaining the correct data. There are several important performance counters to choose from, based on the type of application you are testing. In addition to the lists of counters in this chapter, there is a Web Application Stress Tool online documentation topic titled "Common Performance Monitor Counters" that contains a list of the most common Web-related counters and an explanation of each.

Bb742410.iischp5_iis0505(en-us,TechNet.10).gif

Figure 5.5 View of the Web Application Stress Tool Collection Interval Setting

Settings

Select the Settings node, shown in Figure 5.6, and change the Test Run Time to 1 minute (down from the default setting of 15 minutes). Leave the other settings as they are for the time being, but look over the other options in this view, to get an idea of what can be configured for a script. You can also change the default settings for all new scripts by selecting the Defaults node and changing those options. Remember, though, that the settings in the Defaults node will not affect existing scripts (for example, the Sample Script).

Bb742410.iischp5_iis0506(en-us,TechNet.10).gif

Figure 5.6 The Web Application Stress Tool Settings Node

Users

Select the Users node and double-click the Default user population, indicated by the Default icon. This opens the Users view where you can add and delete users from the default population and create new populations. Each Web Application Stress Tool user stores cookie information and authentication data. Notice that there are 20 users in the default population.

Note: The setting for Web Application Stress Tool users is not the same as the setting for Stress level (threads), which is located in the Concurrent Connections section of the Settings node.

Clients

To return to Script view, choose Scripts from the View menu. Select the Clients node under the Sample Script and double-click the Default client group, indicated by the Default icon. This opens the Clients view, where you can add and delete client machines from the current group or add new groups of client machines. Notice that "localhost" is the only client and that it has a check box next to it. This means that the current machine is acting as a Web Application Stress Tool client. For now, leave the Clients view as is, and select Scripts from the View menu to return to the Script view.

For more information about users and clients in the Web Application Stress Tool, see the Knowledge Base article called "Understanding Threads, Users, and Clients" at https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

Running a Test

Once you have created a script and configured all the settings, users, and clients, you can start the test. Select Sample Script and choose Run from the Scripts menu. Allow the test to complete.

Reporting

To open the Reports view, shown in Figure 5.7, choose Reports on the View menu. Expand the Sample Script report to display all of the report nodes. There should be at least one node with a title that marks the date and time when your most recent test began. To view a summary of that test, expand and select the top level of this report node.

Bb742410.iischp5_iis0507(en-us,TechNet.10).gif

Figure 5.7 View of Web Application Stress Tool Reports

You can select a specific node of the report tree to view more in-depth information. For example, select the Result Codes node to display a sum of the HTTP result codes for every request in the test. Expanding the Perf Counters node displays the counters that have been collected during the test.

Expand the Page Data node and select the first script item. The pane on the right displays detailed information regarding this script item. The page data section of the report provides the response time for each requested page. This period of time, also known as Time To Last Byte (TTLB), is a good source of performance data.

Time To First Byte (TTFB) is the time from the request for the page until the Web Application Stress Tool receives the first byte of data, in milliseconds. TTLB is the total time from the request until the last byte of data has been received on the client, also in milliseconds. This number includes the TTFB time and any additional time needed to receive all of the data for the page. The requests are sorted, and the data is divided into percentiles. For more information about the p-squared algorithm and percentiles, see the Web Application Stress Tool Knowledge Base article at https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx.

In the Report view, you can select Export to CSV from the File menu. Exporting the report values to a format that Microsoft® Excel can read allows you to create charts that show where most of the requests fall. For example, the Excel chart shown in Figure 5.8 illustrates this in a Time To Last Byte report.

Bb742410.iischp5_iis0508(en-us,TechNet.10).gif

Figure 5.8 An Excel Chart of Sample Web Application Stress Tool Results

General Guidelines for Using the Web Application Stress Tool

As a rule, use between 10 and 100 threads per client machine. If you find that you need to run a stress test that requires more than 100 threads per client machine, consider adding more client machines.
Monitor processor utilization on the clients; anything below 80 percent should work well. A client machine may not be capable of sustaining the stress loads when its processor utilization is greater than 80 percent. If this occurs, the test becomes invalid.
When you are adjusting the threads and sockets for a Web Application Stress Tool test, use just one socket (stress multiplier) unless you are performing a special type of test. For more information about this setting, see the Web Application Stress Tool online documentation help topic "Stress Level vs. Stress Multiplier."
Limit the number of users to less than 1,000 unless there is a specific reason that you require more unique users. Although the number of users allowable is limited only by the amount of memory on the client machine(s), you may find that it takes too long for a test to initialize when you have a large number of users.
Avoid creating scripts with more than 1,000, script items. The number of scripts is limited only by the amount of memory on the client machine, but you may find that it takes too long for a test to initialize when your scripts contain large numbers of script items.

Suggestions

In some situations, the Web server processor is the bottleneck. Increase the stress to the point where the number of requests per second starts to decrease, then back the stress off slightly. This is the maximum performance that the Web site can realistically achieve. (You increase the stress by increasing the Stress level setting–the number of threads– or by increasing the number of Web Application Stress Tool client machines.)

On the computer that is monitoring the Web server, use PerfMon to watch the Computername\ System\ % Total Processor Time, Computername\ Web Service\ Connection Attempts/sec, and Computername\ Active Server Pages\ Requests Queued counters of the Web server. If the processors are running at 80 to 85 percent of capacity, then they are most likely to create a bottleneck. On the other hand, if the number of Requests Queued fluctuates considerably during the stress test and the processor utilization remains relatively low, this is an indication that the script is calling a server COM component that is receiving more calls than it can handle. In this case, the server COM component is the source of the bottleneck.

It is a good idea to have an expected peak load that meets your business needs and then create a test that uses enough threads to reach that capacity. This will help you to determine the maximum request rate for the Web application and to confirm that it is in line with the expected peak load.

The amount of personalization in a Web application also plays a significant role in how it performs. The Web Application Stress Tool contains several features that make testing a personalized Web site easy. For example you can create users, and allow the Web Application Stress Tool to save a cookie with each of them. You can also use the Querystring editor to help create and store several sets of name-value pairs that are passed with each request.

Common Web Testing Problems

Running tests against a platform that doesn't match production Web servers
Using a script that doesn't accurately simulate production request behavior
Insufficient processor power or scripts that are too complex for the hardware
Thread safety issues caused by unstable server COM components
In ASP pages, script errors and Global.asa issues

Useful Counters for Stress Testing

The following three tables list counters that provide a good indication of the health of a Web application during a stress test. Start with these counters, and add more to drill down to the cause of a bottleneck or resource leak. (The "Computername" parameter is omitted from the counters listed in these tables in order to save space.)

Table 5.16 Useful Counters for Monitoring Web Server PerformanceDuring Stress Testing

Object	Counter	Purpose/Description
Web Service	Maximum Connections	The maximum number of simultaneous connections to the Web service. Use this number to determine the total number of concurrent connections a server experienced during a test run. If this number grows throughout a test, this is a good indication of a blocking backend dependency.
Web Service	Bytes Total/sec	Shows the sum of bytes sent and received by the HTTP service. If this number is low, it means that IIS 5.0 is not transferring data at a reliable rate. Both ASP pages and HTTP content transfer bytes. Continued
Web Service	Current Connections	Shows the current number of connections to the service. This is the sum of both nonanonymous (authenticated) and anonymous (unauthenticated) users. If this number is at or near the maximum connections allowable, the Web service is at full capacity. Check the Web Site property page for this limit.
Web Service	Current NonAnonymous Users	The number of authenticated users currently connected to the HTTP Server. Use this number to determine the number of authenticated connections the Web server is seeing. If this is not greater than 0 during an authenticated stress run, confirm that you are using valid user accounts and that the appropriate permissions are being applied to the Web content.
Web Service	Not Found Errors	Shows the number of pages that are displaying an HTTP 404 result code to client. Anything greater than 0 is an indication of an invalid test run, because the test script is requesting pages that do not exist.
Active Server Pages	Errors/sec	The number of errors per second, including connection errors, compile errors, and run-time errors. If this number is greater than 0, something is wrong with the test scripts, server configuration, or scripts in ASP pages.
Active Server Pages	Requests/sec	The number of ASP page requests executed per second. Use this number to provide an indication of how heavy the stress on the Web server is. This number does not include HTTP requests and will fluctuate considerably based on the complexity of the ASP pages and the capacity of the Web server.
Active Server Pages	Request Not Found	Unlike the Web Service\ Not Found Errors, this shows only the ASP pages that were not found. These pages display as an HTTP 404 result code to the client. Anything greater than 0 is an indication of an invalid test run, because the test script is requesting pages that do not exist.
Active Server Pages	Requests Rejected	The total number of requests not executed because the queue was full or there were insufficient resources to meet the number of hits that the Web server is seeing. If this number is greater than 0, the stress test is too heavy, or the ASP pages are too complex.
Active Server Pages	Memory Allocated	The total amount of memory currently allocated by ASP. Compare this number to Memory\ Available Bytes and Memory\ Committed Bytes to determine what percentage ASP is using. A ratio of greater than 50 percent during the test would indicate a memory leak in a Server-Side Object.
Active Server Pages	Requests Queued	This should remain close to 0 but it will go up and down when testing a heavily scripted ASP page. The maximum number for this counter varies by the number of processors on the machine and the metabase setting for AspRequestQueueMax. If the limit is reached, your browser will display "HTTP/1.0 Server Too Busy." If this queue grows rapidly as more stress is applied, this indicates that the ASP pages are too complex for the load.
Active Server Pages	Errors During Script Run Time	This is a count of errors that occurred in the ASP pages you are requesting. This should always be 0. If it sporadically shows a value greater than 0, look at the IIS 5.0 log to see which page is causing the problem and check for the error that occurred. If you have the registry set to capture these, the event log will also display the error.
Memory	Page Faults/sec	Displays the number of times a virtual page was not found in memory. If this number is consistently above 0, it indicates that too much memory has been allocated to an application, and not enough to Microsoft® Windows® 2000 Professional, or to the server you are running.
Server	Total Bytes/sec	Shows network activity. This gives you an idea of how close the Web server's network adapter(s) are to being fully utilized. This is particularly useful on "multihomed" Web servers (which have a network adapter for each LAN they connect to).
Process	Private Bytes\ Inetinfo	The current number of bytes the HTTP/ASP service has allocated that cannot be shared with other processes. If this number is consistently large and growing, there is probably a leak in a Server-Side Object. Compare with Process\ Private Bytes: _Total.

Table 5.17 Useful Counters for Monitoring SQL Server Performance During Stress Testing

Object	Counter	Purpose/Description
SQLServer	Cache Hit Ratio	Shows the hit rate that data is found in the cache. If data is not in the cache, the server will have to be read from the disk. This shows memory allocation and therefore indicates whether the server has sufficient memory for the task. A number consistently less than 85 percent indicates a memory problem.
SQLServer	User Connections	Shows the number of active SQL users. Each connection uses 37 KB of memory. Compare this number to the Active Server Pages:Requests/sec counter to get an idea of how much the scripts are really working the SQL server. A large difference may indicate that the test script is not a valid stress of SQL server.
SQLServer	Net–Network Reads/sec	Shows the number of data packets read from the network. An extremely high value for an extended time indicates that either the network card has a problem, or more likely, the application is not using enough stored procedures and is written improperly.
SQLServer	I/O–Lazy Writes/sec	The number of flushed pages per second by the lazy writer. A number consistently above 0 indicates that the lazy writer is constantly working to flush buffers to disk. This means that the application either has a memory leak or the SQL Server requires more memory for normal operation.
SQLServer - Locks	Total Blocking Locks	Shows a lock that forces another process to wait until the current process is complete. An occasional block is normal. If this number is consistently greater than 0 it indicates transaction problems. Some of the basic causes are inefficient query design, poor table design, or slow throughput due to inadequate hardware.
PhysicalDisk	Disk Queue Length	Shows the number of outstanding requests on the disk. Sustained queue lengths on one disk that are greater than 3 indicate a disk or memory problem. It may also indicate that a SQL Server is not set up correctly.

Table 5.18 Useful Counters for Monitoring Performance of Both SQL and Web Servers During Stress Testing

Object	Counter	Purpose/Description
Processor	% Total Processor Time	Shows the amount of time spent processing threads by all CPUs. A number consistently above 85 percent on one or more processors indicates that the test is too intense for the hardware. Make sure you add the 0 through x instances of this counter for multiprocessor machines.
PhysicalDisk	% Disk Time	Requires "diskperf -y" at the command prompt. Shows the percentage of elapsed time that the disk is busy with read/write activity. A number consistently above 80 percent may indicate a memory leak. Make sure you add the 0 through x instances of this counter for multidisk machines.
Memory	Available Bytes	Shows the total bytes of real memory available to the computer, less the number of bytes being used by running applications. Add this number to Memory\ Committed Bytes to get the total amount of memory on the machine.
Memory	Pool Nonpaged Bytes	Shows pages that are used by the operating system that do not leave memory. This will increase with each process, but watch for gradual growth in this counter over a test run. This would indicate an application's repeated inadvertent opening of a file or some other object. Performance will suffer if this approaches within 4 MB of Memory\ Available Bytes.
Memory	Pages/sec	Shows how many pages are being moved to and from the disk to satisfy virtual memory requirements. If the server does not have enough memory to handle its workload, this number will be consistently high.
Memory	Committed Bytes	Shows the size of virtual memory that has been committed to the running applications. Add this number to Memory\ Available Bytes in order to compute the total amount of memory on the machine. Committed bytes should increase as the test is ramping up, but it should remain fairly constant after that.
System	Total Interrupts/sec	Shows the frequency with which this computer is handling hardware interrupts. This gives you a good idea of how busy the whole system is.
Object	Threads	Threads are the basic executable entity that can execute instructions in a processor. If this number continues to rise over time, open the Computername\ Process\ Thread Count counter to discover which instance is creating all of the threads.
Process	Private Bytes: _Total	Shows the current number of bytes that all instances have allocated that cannot be shared with other processes. Make sure you select the _Total instance from the list, in addition to any other instances you suspect may be consuming too much memory.

Suggested Values

Table 5.19 lists some of the counters that are generally useful for monitoring your server, with suggestions about appropriate or dangerous values. Most of these values are given in relative terms, because actual numbers vary from site to site. For example, the Computername\ Active Server Pages\ Transactions/ sec counter is not relevant to a Web site with only static content, and Computername\ Disk\ Avg Disk Bytes/Transfer is different for different kinds of controllers and drives. (Again, "Computername" is omitted, in order to conserve space.)

Table 5.19 Useful Counters for Monitoring Web Server Performance

Object:Counter	Preferred or Ideal Value
Memory\ Pages/sec	0-20 (bad if over 80; probably indicates insufficient RAM).
Memory\ Available Bytes	At least 4 MB.
Memory\ Committed Bytes	Not more than about 75% of physical memory size.
Memory\ Pool Nonpaged Bytes	Steady (slow rise may indicate a memory leak).
System\ Context Switches/sec	As low as possible.
Processor\ % Processor Time	Less than 75%.
Processor\ Interrupts/sec	Depends on processor, and on network hardware and drivers. Up to 3,500 for 90 megahertz (MHz) Pentium; more than 7,000 for 200 MHz Pentium. Lower is better. If the value is too high, try moving some hardware devices to a different server.
Processor\ System Processor Queue Length	Less than 2 (but see the text for exceptions).
Disk (Logical or Physical)\ % Disk Time	As low as possible.
Disk (Logical or Physical)\ Queue Length	Less than 2.
Disk (Logical or Physical)\ Avg. Disk Bytes/Transfer	As high as possible.
Internet Information Service Global\ Cache Hits %	As high as possible.
Web Service\ Bytes Total/sec	As high as possible.
Active Server Pages\ Request Wait Time	As low as possible.
Active Server Pages\ Requests Queued	Zero.
Active Server Pages\ Transactions/sec	As high as possible.

In addition to these, you will find the Computername\ System\ Threads, Computername\ System\ Processes, Computername\ System\ Context Switches/sec and other System Object counters useful for monitoring your server's use of System resources.

Examining the Results

If you find problems, you can use these and other counters to analyze them. For example, if you see evidence of a memory leak (a slow rise in committed bytes or pool nonpaged bytes), you should monitor processes. Similarly, if you see evidence of a disk bottleneck, you can examine reads and writes separately as you begin to track down the problem.

Note: When interpreting the counters, remember that they show the most recently observed value, not a long-term average, unless they specify otherwise. You can use the log mode in PerfMon to determine the average values.

If you support a SQL database, be sure that your SQL Server Objects report events to Windows 2000 Server if the objects suffer errors. If, for example, your server runs 10 threads, and all of those threads become involved in SQL Server Objects that hang, ASP processing comes to a complete halt until you stop and restart the server. You can examine the event log and the Connection Attempts/ sec counters to detect this condition.

Internet Information Services Global\ Cache Hits % should be high because otherwise you are thrashing your server's disk. On the other hand, when you first start your Web server this number is going to be low until the cache has actually been populated with files. If you see a low number a few minutes after you bring up the server, you can ignore it. If the number is still low after you've had thousands of hits, something is probably wrong unless (for example) you are maintaining a large database on your server, and you have users performing a wide variety of unrelated queries. If very few pieces of information are requested more than once, the number of cache hits is going to be small; there isn't much you can do about it unless you can afford enough RAM to put the entire database in memory. This, at least, will provide a considerable decrease in access time on the database server.

Baseline Logging

You can use the counters mentioned in Table 5.19 to generate a baseline log that shows the characteristics of your server under ordinary conditions. Such a log should cover at least one week of normal operation, so that it contains enough information to give you a good sense of your server's behavior. Shorter logs that you create from time to time can help you decide when to upgrade.

Whenever you upgrade, you should generate another baseline log. You can compare this to previous logs, in order to discover the actual effects your upgrade is having on performance and capacity.

You can also log the counters of the Job Object to find out how much of your server's capacity is in use for Web service. In PerfMon, these counters provide an overview; if you host multiple Web sites and want a detailed breakdown, the IIS 5.0 log is where you need to look.

Additional Resources

The following Web sites and books provide additional information about IIS 5.0 and about other features of Windows 2000 Server, as well as useful resources for performance tuning.

Web Links

https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx

The Web Application Stress Tool is available here.

https://microsoft.com/msj/0398/dcom.htm

This site contains information about the International Standards Organization's (ISO) Open Systems Interconnection (OSI) (the so-called "seven-layer model").

Books

Web Performance Tuning by Patrick Killelea; Linda Mui, Editor, 1998, Cambridge: O'Reilly & Associates.

Tools

Playback

This tool records traffic accessing an IIS 5.0 Web site. It then replays that captured traffic on the same server, or on a different server that mirrors the content of the server on which the recording took place. Playback is included on the Resource Kit companion CD.

Chapter 5 - Monitoring and Tuning Your Server

On This Page

Using This Chapter

Memory

Memory Requirements of a Server Running IIS 5.0

Monitoring Overall Server Memory

Memory Monitoring Specifics

Tuning TCP Sockets

Monitoring the Working Set of the IIS 5.0 Process

About the Inetinfo Working Set

Analyzing the Working Set Data

The IIS Object Cache

Monitoring the File System Cache

How IIS 5.0 Uses the File System Cache

Using PerfMon to Monitor the File System Cache

Analyzing the File System Cache Data

Suggestions for Optimizing Memory Usage

Preventing Processor Bottlenecks

Monitoring Server Processors

Using PerfMon to Monitor Processor Activity

Analyzing Processor Activity Data

Process Throttling

Monitoring Connections

Analyzing Connection Data

Monitoring Threads

Suggestions for Improving Processor Usage and Performance

Network I/O

Network Bandwidth Requirements of a Server Running IIS 5.0

Monitoring the Network Connection

Bandwidth and Capacity

Network Specifics (Data Transmission Rates, File Transfers, TCP Connections)

Optimizing the Network Connection

Lengthening Connection Queues

Using HTTP Keep-Alives

Disk I/O

Monitor Settings and Relevant Counters

Monitoring a Remote Computer

Web Applications

Tuning the ASP Queue and Thread Pool

How This Affects Server Administration

Optimizing for Web Applications

Short-Term Problems and Temporary Fixes

Tuning Tips

Monitoring Security Overhead

Measuring Security Overhead with WCAT

Testing Security Features

Using PerfMon to Track Anonymous and Nonanonymous Connections, and Not-Found Errors

Counting Not-Found Errors

Analyzing the Data and Planning Upgrades

Tools

The System Monitor

Performance Counter Check

The HTTP Monitoring Tool

NetStat and NetMon

Process Viewer, Process Explode, Process Monitor, and Event Viewer

Web Application Stress Tool and WCAT

Getting Started with the Web Application Stress Tool

Installing the Web Application Stress Tool

Using the Web Application Stress Tool Sample Script

Running a Test

General Guidelines for Using the Web Application Stress Tool

Suggestions

Common Web Testing Problems

Useful Counters for Stress Testing

Suggested Values

Examining the Results

Baseline Logging

Additional Resources

Web Links

Books

Tools

Additional resources