ASP .NET Application Monitoring

This article describes the basic monitoring required to drill down any ASP .NET related performance issues. It's always good to have more performance data than not enough, especially when you experience a problem that is not easily reproduced. This article will describe some necessary Performance Counters and logs required to be looked into while analysing ASP .NET application's performance issues.

Monitoring Performance Counters:
There are many performance counters that are useful for monitoring performance of ASP .NET application. Below are the few important ones. 

Processor(_Total)\% Processor Time

Process(aspnet_wp)\% Processor Time

Process(aspnet_wp)\Private Bytes

Process(aspnet_wp)\Virtual Bytes

Process(aspnet_wp)\Handle Count

Microsoft® .NET CLR Exceptions\# Exceps thrown / sec

ASP.NET\Application Restarts

ASP.NET\Requests Rejected

ASP.NET\Worker Process Restarts (not applicable to IIS 6.0)

Memory\Available Mbytes

Web Service\Current Connections

Web Service\ISAPI Extension Requests/sec

Monitoring Logs:

Event Log:

It is critical to monitor the event log for messages from ASP.NET and Microsoft Internet Information Server (IIS). ASP.NET writes messages to the application log, for example, each time the aspnet_wp worker process terminates IIS 6.0 writes messages to both the application and/or system logs, for example, each time the w3wp worker process reports itself unhealthy or crashes. It is quite easy to write a .NET application that reads the application log and filters out messages from ASP.NET and IIS, and fires an alert (sends e-mail or dials a pager) if necessary.

W3C and HTTPERR Logs:

First, enable W3C logging for IIS through the Internet Information Services (IIS) Manager. This log can be configured to include various data about the requests, such as the URI, status code, and so on. Scan the log for error codes such as 404 Not Found, and take action to correct links, if necessary. It also contains substatus code in the log and is useful for debugging. IIS uses substatus codes to indentify specific problems. For example, 404.2 indicates that the ISAPI extension handling the request is locked down. 

New for IIS 6.0, malformed or bad requests and requests that fail to be served by an Application Pool are logged to the HTTPERR log by HTTP.SYS, the kernel-mode driver for handling HTTP requests. Each entry includes the URL and a brief description of the error.

Check the HTTPERR log for rejected requests. Requests are rejected by HTTP.SYS when the kernel request queue is exceeded, and when the application is taken offline by the Rapid Fail Protection feature. When the first issue occurs, the URL is logged with the message QueueFull, and when the second occurs, the message is AppOffline. Check the HTTPERR log for requests lost due to a worker process crash or hang. When this occurs the URL will be logged with the message,Connection_Abandoned_By_AppPool, for each in-flight request. An in-flight request is one that was sent to a worker process for processing, but did not complete before the crash or hang.