A memory deficit can drastically reduce the performance of IIS. Here are some important counters you need to keep an eye on:
– Available MB – This is the amount of physical memory immediately available for allocation to a process, or for system use. It is equal to the sum of memory assigned to the standby (cached), free and zero page lists. A healthy system should have more than 50% of its memory available.
– Pages/sec – This is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It is the sum of Memory\Pages Input/sec and Memory\Pages Output/sec. Pages / sec tracks the numbers of pages, so you can compare it to other counts such as Memory\Page Faults/sec. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files. If this number remains high (e.g. >500), in combination with low Available Mbytes then you could consider memory a possible bottleneck.
An obvious target of your monitoring plan is CPU utilisation. Here are two key metrics:
– Processor\% Processor Time – This is the percentage of elapsed time the processor spends on a non-Idle thread. It is calculated by measuring the percentage of time the processor spends executing the idle thread and then subtracting that value from 100%. Each processor has an idle thread that consumes cycles when no other threads are ready to run. This counter is the primary indicator of processor activity and displays the average percentage of busy time observed during the sample interval. Here, values above 80-85% would probably raise some questions.
– System\Processor Queue Length – This is the number of threads waiting for processor time when the server’s processors are busy servicing other threads. There is one single queue for processor time even on computers with multiple processors.
The key here is to monitor those two counters together. As a rule of thumb, if queue length is consistently over 2 and % Processor Time remains high, then processors are a bottleneck.
Disk & Network
– Physical Disk\% Disk Time – this is the percentage of elapsed time that the selected disk drive was busy servicing read or write requests. Under normal conditions this counter should stay low.
– Physical Disk\Avg. Disk Bytes/Transfer – This is the average number of bytes transferred to or from the disk during write or read operations. A higher value for this counter indicates an efficient disk.
– Physical Disk\Avg. Disk Queue Length – This is the average number of read and write requests that were queued for the selected disk during the sample interval. As a general rule a value over 2 (per disk, i.e. per counter) for extended periods of time is undesirable.
– Network Interface\Bytes Total/sec – This value is the rate at which bytes are sent and received over each network adapter, including framing characters. High values indicate a large number of successful transmissions.
Web Service Cache
The File Cache counters indicate whether you have enough memory for IIS:
– File Cache Hits – Total number of successful lookups in the user-mode file cache since service startup. The preferred value depends on content. For example, for static content, the value should be high.
– File Cache Hits % – The ratio of user-mode file cache hits to total cache requests (since service startup). A low counter value (combined with a low Kernel: URI Cache Hits % value) could possibly mean that you need to examine why your files are not being cached.
– File Cache Misses – Total number of unsuccessful lookups in the user-mode file cache since service startup.
– File Cache Flushes – The number of files removed from the user-mode cache since service startup.
URI cache counters provide performance metrics regarding websites and web applications that might be running on your server.
– URI Cache Flushes – Counts the number of URI cache flushes that have occurred since the service startup. Files are flushed if a response is taking longer than specified in the threshold or if a file was edited or modified.
– URI Cache Hits – Counts the number of successful lookups in the URI cache since the service startup. A low value for this counter is a strong indication that requests are not finding cached responses.
– URI Cache Hits % – The ratio of URI Cache Hits to total cache requests since service startup.
– URI Cache Misses – Total number of unsuccessful lookups in the user-mode URI cache since service startup. You might want to investigate for issues if this value is high, in combination with a low URI Cache Hits value.
These counters provide important information about the number of users accessing the web service and the volume of data exchanged.
– Bytes received/sec – This counter shows the rate that data is received by the Web service.
– Bytes sent/sec – This is the rate that data is sent by the Web service.
– Bytes total/sec – The sum of the two counters above. It indicates the total rate of bytes transferred by the Web service.
– Connection attempts/sec: The rate that connections to the Web service are attempted.
– Get Requests/sec – This is the rate of HTTP GET requests. High values indicate that your web server is overloaded.
– Post Requests/sec – This is the rate HTTP POST requests. Again, high values suggest the need to take measures.
– Current Connections – number of current connections to the Web service. This counter’s interpretation depends upon many variables, such as the type of requests (ISAPI, CGI, static HTML, etc.), CPU utilization, et cetera. So you’d need to do some investigation to triage any underlying issues.