[This is preliminary documentation and subject to change]
By using the performance counters built into Windows Whistler and IIS, administrators can monitor performance to determine equipment needs. After changes are made, monitoring can be used to determine if the changes had the desired effect, or if further changes are needed.
This topic describes the following:
Problems caused by memory shortages can often appear to be problems in other parts of the system. You should monitor memory first to verify that your server has enough, and then move on to other components. To run Windows Whistler and IIS 6.0, the minimum amount of RAM a dedicated Web server needs is 128MB, though depending on the resource needs of your custom applications, more RAM may be necessary. If your custom applications do require large amounts of memory resources, use 256 MB to 1GB of RAM. Additional memory is particularly beneficial to e-commerce sites, sites with a lot of content, and sites that experience a high volume of traffic.
Note
Windows 2000 Advanced Server can support up to 8GB
of RAM and Windows 2000 Datacenter can support up to 64GB. Every
instance of the IIS worker process can address up to 2GB, so if you
had a sufficiently large system, the cumulative memory used by all
the IIS-related processes could go beyond 4GB.
To determine if the current amount of memory on your server will be sufficient for your needs, use the System Monitor tool (formerly known as PerfMon) built in to Windows Whistler. The System Monitor graphically displays counter readings as they change over time.
Log the following counters to determine if there are performance bottlenecks associated with memory:
| Counters | Description |
|---|---|
| Memory\ Available Bytes | Try to reserve at least ten percent of memory available for peak use. |
| Memory\ Page Faults/sec
| 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 (measured by Transition Faults/sec). If the page must be retrieved from disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults without consequence. However, hard faults can cause significant delays. Page Faults/sec is the overall rate at which the processor handles faulted pages, including both hard and soft page faults. Pages Input/sec is the total number of pages read from disk to resolve hard page faults. Page Reads/sec is the number of times the disk was read to resolve hard page faults. Pages Input/sec will be greater than or equal to Page Reads/sec and can give you a good idea of your hard page fault rate. If these numbers are low, your server should be responding to requests quickly. If they are high, it may be because you've dedicated too much memory to the caches, not leaving enough memory for the rest of the system. You may need to increase the amount of RAM on your server, though lowering cache sizes can also be effective. |
| Memory\ Cache Bytes
Web Service Cache\ File Cache Flushes Web Service Cache\ File Cache Hits Web Service Cache\ File Cache %
| Memory\ Cache Bytes reveals the size of the File System Cache, which is set to use up to 50 percent of available physical memory by default. Since IIS automatically trims the cache if it is running out of memory, keep an eye on the direction in which this counter trends. |
| Page File Bytes\ Total | This counter reflects the size of the paging file(s) on the system. The larger the paging file, the more memory the system commits to it. Windows Whistler 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 improves paging file performance (use drives that do not contain your site's content or log files). Remember that the paging file on the system drive should be at least twice the size of physical memory, so that the system can write the entire contents of RAM to disk if the system unexpectedly locks up or shutdown. |
| Memory\ Pool Paged Bytes
Memory\ Pool Non-paged Bytes Process (inetinfo)\ Virtual Bytes Process (w3svc)\Virtual Bytes Process (dllhost#n)\ Virtual Bytes Process (inetinfo)\ Working Set Process (dllhost#n)\ Working Set | Memory\ Pool Paged Bytes and Memory\ Pool Non-paged Bytes monitor the pool space for all processes on the server. The Virtual Bytes counters monitor the amount of virtual address space reserved directly by IIS 6.0, either by the Inetinfo process (in which the core of IIS runs when set to standard mode) or by the Dllhost processes (in which isolated or pooled applications run) instantiated on your server. The Working Set counters measure the number of memory pages used by each process. Be sure that you monitor counters for all instances of Dllhost on your server; otherwise, you will not get an accurate reading of pool space used by IIS. 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 6.0, threads that service connections are stored in the non-paged pool along with other objects used by the service, such as file handles and sockets. |
Besides adding more RAM, try the following techniques to enhance memory performance. For specific details on how to perform these techniques, see the Internet Information Services Resource Kit:
With users demanding quick response time from Web sites and the increasing amount of dynamically generated content on these sites, a premium is placed on fast and efficient processor usage. Bottlenecks occur when one or more processes consume practically all of the processor time. This forces threads that are ready to be executed to wait in a queue for processor time. Adding other hardware, whether memory, disks or network connections, to try to overcome a processor bottleneck will not be effective and will frequently only make matters worse.
IIS is designed to scale on multiprocessor machines, but poor Web site and application design can impact this ability to scale. Be sure to test the scalability of your Web site and applications on a multiprocessor machine.
Be aware, however, that the biggest performance gains with IIS occur when you resolve inadequate memory issues. Before making any decisions about changing the number of processors on your Web servers, rule out memory problems and then monitor the following performance counters. See the Counters Reference for a complete list of counters and counters related to performance.
| Counter | Description |
|---|---|
| System\ Processor Queue Length | This counter displays the number of threads waiting to be executed in the queue that are shared by all processors on the system. If this counter has a sustained value of two or more threads, you have a processor bottleneck on your hands. |
| Processor\ %Processor Time | Processor bottlenecks are characterized by situations in which Processor\ % Processor Time numbers are high while the network adapter card and disk I/O remain well below capacity. On a multi-processor computer, it's a good idea to examine the Processor\ % Processor Time counter to pick up any imbalance. |
Thread (svchost/host number)\Context Switches/sec System\ Context Switches/sec | If you decide to increase the size of any of the thread pools, you should monitor this counter. Increasing the number of threads may increase the number of context switches to the point where performance decreases instead of increases. Ten thousand or more context switches per processor is high. If see these kinds of numbers, consider reducing thread pool size. Balancing threads against overall performance as measured by connections and requests can be difficult. Any time you tune threads, follow-up with overall performance monitoring to see if performance increases or decreases. To determine if you should adjust the thread count, compare the number of threads and the processor time for each thread in the process to the total processor time. If the threads are constantly busy, but are not fully using the processor time, performance may benefit from creating more threads. However, if all the threads are busy and the processors are close to their maximum capacity, you are better off distributing the load across more servers rather than increasing the number of threads. |
| Processor\ Interrupts/sec Processor\ % DPC Time | Use these counters to determine how much time the processor is spending on interrupts and deferred procedure calls (DPCs). These two factors can be another source of load on the processor. Client requests can be a major source of each. Some new network adapter cards include interrupt moderation, which accumulates interrupts in a buffer when the level of interrupts becomes too high. |
To observe the efficiency of a multiprocessor computer, use the following counters.
| Counter | Description |
|---|---|
| Processor(_Total)\ % Processor Time | A measure of processor activity for all processors
in the computer. This counter sums the average non-idle time of all processors during the sample interval and divides it by the number of processors. For example, if all processors are busy for half of the sample interval, on average, it displays 50%. It also displays 50% if half of the processors are busy for the entire interval, and the others are idle. |
| Thread\ % Processor Time | The amount of processor time for a thread. |
Controlling processor affinity can improve performance by reducing the number of processor cache flushes as threads move from one processor to another. This might be a good option for dedicated file servers. However, be aware that dedicating a program to a particular processor may not allow other program threads to migrate to the least-busy processor.
If you want to assign a particular process or program to a single processor to improve its performance at the expense of other processes use the Set Affinity command in the Task Manager.
Note
Notes
The network is the line through which clients send requests to your server. The time it takes for those requests and responses to travel to and from your server is one of the largest limiting factors in user-perceived server performance. This request-response cycle time is called latency, and latency is almost exclusively out of your control as a Web server administrator. For example, there is little you can do about a slow router on the Internet, or the physical distance between a client and your server.
On a site consisting primarily of static content, network bandwidth is the most likely source of a performance bottleneck. Even a fairly modest server can completely saturate a T3 connection (45Mbps) or a 100Mbps Fast Ethernet connection. You can mitigate some of these issues by tuning the connection you have to the network and maximizing your effective bandwidth as best you can.
The simplest way to measure effective bandwidth is to determine the rate at which your server sends and receives data. There are a number of performance counters that measure data transmission in many components of your server. These include counters on the Web, FTP, and SMTP services, the TCP object, the IP object, and the Network Interface object. Each of these counters reflects different Open System Interconnectivity (OSI) layers. For a detailed list of these counters and their analysis, see the Counters Reference:
| Counters | Description |
|---|---|
| Network Interface\ Bytes Total/sec | To determine if your network connection is creating a bottleneck, compare the Network Interface\ Bytes Total/sec counter to the total bandwidth of your network adapter card. To allow headroom for spikes in traffic, you should usually be using no more than 50 percent of capacity. If this number is very close to the capacity of the connection, and processor and memory use are moderate, then the connection may well be a problem. |
| Web Service\ Current Connections
Web Service\ Maximum Connections Web Service\ Total Connection Attempts | If you are running other services on the computer that also use the network connection, you should monitor these counters to see if your Web server can use as much of the connection as it needs. Remember to compare these numbers to memory and processor usage figures so that you can be sure that the connection is the problem, not one of the other components. |
Since IIS writes logs to disk, there is regular disk activity even with 100 percent client cache hits. Generally speaking, if there is high disk read or write activity other than logging, this means that other areas of your system need to be tuned. For example, hard page faults cause large amounts of disk activity, but they are indicative of insufficient RAM.
Accessing memory is faster than disk seeks by a factor of roughly 1 million (nanoseconds versus milliseconds). It is obvious then that searching the hard disk to fill requests degrades performance. The type of site you host can have a significant impact on the frequency of disk seeks. If your site has a very large file set that is accessed randomly, if the files on your site tend to be very large, or if you have a very small amount of RAM, then IIS is unable to maintain copies of the files in RAM for faster access.
Typically, you will use the Physical Disk counters to watch for spikes in the number of disk reads when your server is busy. If you have enough RAM, most connections will result in cache hits unless you have a database stored on the same server, and clients are making dissimilar queries. This situation precludes caching. Be aware that logging can also cause disk bottlenecks. To avoid bottlenecks caused by logging, put your logs on a separate device. If there are no obvious disk-intensive issues on your server, but you see lots of disk activity anyway, you should check the amount of RAM on your server immediately to make sure you have enough memory.
To determine the frequency of disk access, log the following counters:
| Counters | Description |
|---|---|
| Processor\ % Processor Time
Network Interface Connection\ Bytes Total/sec PhysicalDisk\ % Disk Time PhysicalDisk\Current Disk Queue Length | If all four of these counters have high values, then the hard
disk is not causing a bottleneck for your site. However, if the %
Disk Time is high and the processor and network connection are not
saturated, then the hard disk may be creating a bottleneck. The
Current Disk Queue Length value should not be greater than 2 for
any sustained period of time.
If the Physical Disk performance counters are not enabled on your server, open a command line and use the diskperf -yd command. |
Balancing performance with users' concerns about the security of your Web applications is one of the most important issues you will face, particularly if you run an e-commerce Web site. Since secure Web communication requires more resources than non-secure Web communications, it is important that you know when to use various security techniques, such as the Secure Sockets Layer (SSL) protocol or IP address checking, and when not to use them. For example, your home page or a search results page most likely doesn't need to be run through SSL. However, when a user goes to a checkout or purchase page, you will want to make sure that page is secure.
If you do use SSL, be aware that establishing the initial connection is five times as expensive as reconnecting using security information in the SSL session cache. The default timeout for the SSL session cache has been changed five minutes in Windows 2000 and later. Once this data is flushed, the client and server must establish a completely new connection. If you plan on supporting long SSL sessions, consider lengthening this timeout with the ServerCacheTime registry setting. If you expect thousands of users to connect to your site using SSL, a safer approach is to estimate how long you expect SSL sessions to last, then set the ServerCacheTime parameter to slightly longer than your estimate. Do not set the timeout much longer than this or else your server may leave stale data in the cache. Also, make sure that HTTP Keep-Alives are enabled (on by default). SSL sessions do not expire when used in conjunction with HTTP Keep-Alives unless the browser explicitly closes the connection.
In addition to all security techniques having performance costs, Windows Whistler and IIS 6.0 security services are integrated into a number of operating system services. This means that you can't monitor security features separately from other aspects of those 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 the following:
Note
If a server is used both for running IIS 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 services from running
efficiently. It is highly recommended that you refrain from running
a high-traffic Web server on a domain controller.