How to Monitor Microsoft IIS
Nassos Katsaounis, of Server Density.
Published on the 21st July, 2016.
Internet Information Services (IIS) serves no less than a third of all websites out there. With rich features, good performance, and major security improvements in the last few incarnations, opting for IIS might come naturally, especially when you need to host your website under Windows.
As with any business critical app, running IIS without consistent and targeted monitoring, is an accident waiting to happen. Here is how we monitor IIS here at Server Density.
Monitoring IIS, and any web server, involves two types of counters:
- System-related: Memory, Processor, Disk performance, et cetera
- Web server counters: Web Service and Web Service Cache
Let’s start with system-related counters.
Monitor IIS: Memory
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.
This TechNet article delves deeper into Web Service cache counters.
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.
In addition to these counters, if you are developing web applications with ASP.NET there are some useful ASP.NET Performance Counters you should keep track of, to ensure smooth running of your applications and server.
For a more detailed overview of Web Service counters check out this TechNet article.
Windows OS comes equipped with some handy tools you can use out of the box.
One of the simplest ways to perform monitoring in Windows, Performance Monitor is a real-time graphical monitoring tool that ships with Windows and provides steady measurements for all sorts of operating systems and web service counters.
Performance monitor offers numerous options related to monitoring performance, such as display of metrics in graphs or reports, defining alerts or exporting data and allowing for extensive configuration of settings.
For more information on how to use Windows Performance monitor visit TechNet’s guide.
IIS events show up in the Application Log of the Event Viewer. They can give you a detailed first look at a problem. When the following keywords appear in column “Source” of the Application Log, they might indicate issues possibly related to IIS activity:
NNTP Service (NNTPSVC), WWW Service (W3SVC), FTP Service (MSFTPSVC), SMTP Service (SMTP SVC), Active Server Pages, Microsoft Distributed Transaction Control (MSDTC), Certificate Services related to SSL (CERTSVC).
For more information on viewing IIS Events in the Event Viewer check out this MSDN article. As an alternative to Event Viewer, you can use one of the many 3rd party log parsing tools like Visual Log Parser, Elastic stack, Stackify, and Splunk.
The Windows Task Manager offers a quick overview of CPU and memory usage related to IIS services inetinfo.exe and (especially) w3wp.exe. By selecting some useful columns to display, such as Working Set Delta for memory you can see if there is a memory leak somewhere, degrading your web server’s performance. For more information on how to use Task Manager see here (Windows 7) or here (Windows 8/10).
IIS starts a new Working Process (w3wp.exe) for each Application Pool setup. For a more detailed picture, however, you will need to monitor the Worker Processes in IIS Manager – read on.
IIS Manager and IIS 7 improvements
One of the most important tools related to IIS is IIS Manager, a graphical user interface enabled application that ships with Windows. Although IIS Manager is primarily responsible for configuring and managing IIS operation, the introduction of IIS 7 saw two major advances in diagnosing and troubleshooting web sites and applications.
The first refers to real-time state information about application pools, worker processes, sites, application domains, and running requests. The second involves detailed trace events that track a request throughout the complete request-and-response process.
Thus, Health and Diagnostics, now available within IIS Manager, include the following features:
- Failed Request Tracing Rules – Failed request tracing rules let you capture an XML-formatted log of a problem when it occurs, so that you don’t necessarily have to reproduce the problem before you start troubleshooting.
- Logging – By configuring IIS to log site visits, when users access your server IIS logs the information. The logs provide valuable information that you can use to identify any unauthorized attempts to compromise your Web server.
- Worker Processes – The worker processes feature lets you monitor sites, application pools, server worker processes, application domains, and requests.
Third party tools
If you are looking for richer features, reports and analytics, you will probably want to check out 3rd party tools such as Site24x7, Lean Sentry, Solarwinds, AppDynamics, and Nagios Log Server, that offer a wealth of features and free trials to start with.
At this point, we might opt for a little self-praise, as Server Density has some monitoring power reserved for IIS too. Make sure to check out our elastic graphs and powerful analytics, and register for a free trial.
Whether your website serves thousands of visitors or a handful of internal users, monitoring your web server’s activity is key. Windows provides several metrics and built-in tools to keep an eye on availability, performance and response times, but you should also try one of the numerous 3rd party tools.
So what about you? What are your thoughts on IIS monitoring?