ASP.NET Tips #18 - Where are your custom performance counters?

Performance counters are a great way to watch how you are using .NET, IIS, the database, and much more on the operating system. However, the real benefits of performance counters come when you start using them to record data that's unique to you, such as how many logins you've had, what's the average time for your web service to process a specific request, and anything else you can imagine.

With .NET's excellent PerformanceCounter class doing the work for you, creating performance counters is so simple a manager could do it. By spending no more than an hour on planning and implementation, you can get a ton of actionable information out of your application in production. Performance counters are cheap, easy, and you can never have enough.

However, it could be interesting to broaden the scope to get key values in order to have a global vision of how the whole server is behaving instead of just IIS or ASP.NET. You need to check CPU, Memory, etc and put this in balance with your application and IIS.

Here is a non-exhaustive list of counters you could use to get this vision:

For IIS

Memory:

• Available Mbytes: Allows you to see the available memory. It's important to be sure the server isn't undersized for the needs of the application
• % Commited Bytes In Use: Allows you to see the used memory. It's interesting to put this in balance with the Available Mbytes counter

Process (For all W3WP.exe processes):

• % Processor Time: Allows you to see the CPU consumption for a given process
• Virtual Bytes: Allows you to see the virtual memory for the process W3WP.exe
• Private bytes: Allows you to see the private memory for the process W3WP.exe

Processor (All instances):

• % Processor Time: Allows you to put in balance the total CPU consumption with each W3WP.exe. For example, if your server is consuming 90% of CPU and the sum of the W3WP.exe CPU consumption is 10%, you clearly have an issue elsewhere than IIS

HTTP Service Request Queues (All instances):

• CurrentQueueSize: Allows you to see the size if the HTTP Kernel side queue and thus to see if a huge number of requests are getting queued without being handled by the User Mode side
• RejectedRequests: Allows you to see if requests are rejected from Kernel side without being handled by the User Mode side

APP_POOL_WAS (For all listed Application Pools):

• Current Application Pool State: Allows you to see the state of an Application Pool
• Current Application Pool Uptime: Allows you to see if the Application has been restarted or not (relay useful during a load test)

For ASP.NET

ASP.NET Applications (For all applications you want to monitor):

• Compilations Total: Allows you to see the number of compiled pages
• Request Bytes In Total: Allows you to see the number of received bytes
• Request Bytes Out Total: Allows you to see the number of sent bytes
• Request Execution Time: Allows you to see the execution time for the most recent request
• Request Wait Time: Allows you to see the time spent in the queue before being handled for the most recent request
• Requests Executing: Allows you to see the number of requests being executed
• Request in Application Queue: Allows you to see the number of requests in the queue
• Requests Timed Out: Allows you to see the number of timed-out requests
• Requests/Sec: Allows you to see the number of requests executed per seconds
• Sessions Active: Allows you to see the number of active sessions

ASP.NET V4.0.30319:

• Application Restarts: Allows you to see the number of restarts for the Application Domain

With all this information, you should be able to determine the threshold where your application is behaving as expected and the threshold where problems should start to occur.