Understanding .NET Performance Counters

This is in continuation from the previous article on performance counters for SQL Server. In this article we will look at some of the useful .NET Performance counters we need to monitor. Use these as the baseline counters. This is NOT the exhaustive list. But surely a basic top 25 to keep a watch on for sure.

Performance Counter	Description
Processor (_Total)\% Processor Time	Gives an indicator of the total processor utilization in the machine. A value of 80-85% is acceptable. Lower the better.
.NET CLR Exception\# of Excep Thrown /sec (_Global_)	This is the number of managed code exceptions thrown per second. More the exceptions more is the performance degradation. This has to be 0 under normal circumstances. Note: Response.Redirect, Server.Transfer and Response.End all raise a ThreaAbortException. A metrics of 5% of RPS is kept for this counter to consider it as a valid level.
.NET CLR Interop\# of Stubs	Indicates the number of stubs created by the CLR. This value has to be lower as much as possible. But for calls being made from managed and un-managed and vice-versa, this counter gives an indication to the interaction between COM and managed code. There is always a performance penalty for such interactions.
.NET CLR Loading\Current Assemblies (_Global_)	Indicates and records the number of assemblies that are loaded in the process. It includes all the AppDomains in the system.
.NET CLR Loading\Rate of Assemblies	Rate at which assemblies are loaded into the memory per second.
.NET CLR Loading\Bytes in Loader Heap	Indicates the number of bytes commited by the class loader across all AppDomain. This counter has to be in a steady state, else large fluctuations in this counter indicates there are too many assemblies loaded per AppDomain.
.NET CLR Memory\# Bytes in all Heaps	This couter indicates the current memory allocated for the GC heap. Or it can be seen as the number of bytes committed by managed objects. This has to be less than the Process\Private Bytes counter. The difference between the same is the number of bytes committed by unmanaged objects.
The above counter is an classic and key counter to keep our eye's on. There can be memory requirement because of excessive application demands while using large data sets into memory, excess cache entries, using reg-ex and string parsing, excess view-state or excessive session objects. All these attribute to heavy memory requirement. Hence use this counter to start the diagnostic. Other tools as CLR Profiler can take us much closer to the problem.
.NET CLR Memory\# Induced GC	This counter records the explicit call the the GC.Collect method. This value has to be closer to 0.
.NET CLR Memory\% Time in GC	This indicates the percentage of time spent performing the last GC. Lower the value in the range of 5-10% is an acceptable value. There can be spikes at this counter but those are acceptable. There is a temporary suspension of all the threads during this activity. Hence there is a performance overhead we incur. Allocating large strings to cache, heavy string operations etc leave a lot of memory spaces that the GC has to clean up. Avoid such operations.
.NET Data Provider for SQLServer\NumberOfActiveConnections	Number of active connection in the pool in-use presently.
.NET Data Provider for SQLServer\NumberOfFreeConnections	Number of connections free for use in the pool presently.
.NET Data Provider for SQLServer\SoftConnectsPerSecond	Indicates the number of connections we receive from the pool every second.
ASP.NET\Application restarts	Has to be 0 for an ideal scenario.
ASP.NET\Request Execution Time	Time in ms to execute the last request.
ASP.NET\Request Wait Time	Time in ms to wait before the request got executed.
ASP.NET\Requests Current	Indicates the total number of requests handled by the ASP.NET ISAPI. This counter needs to be lesser than the requestQueueLimit defined at the processModel configuration. Beyond this the requests are rejected.
ASP.NET\Worker Process restarts	This is the number of times the aspnet_wp was restarted. This has to be 0 for an ideal scenario. More the restarts/recycling of the worker process more is the blocking of the application.
ASP.NET Applications\Cache Total Hit Ratio	This is the total hit-to-miss ration of all cache requests. This needs to be as high as possible.
ASP.NET Applications\Compilations Total	This indicates the number of ASAX, ASCX, ASHX, ASPX and ASMX files that are compiled. This counter needs to be on a steady value as once compiled these are re-loaded by in the next request directly.
ASP.NET Applications\Errors During Execution	The total number of run-time errors. This needs to be as low as possible.
ASP.NET Applications\Requests/sec	This is the total number of requests executed per second
Process\% Processor Time (aspnet_wp and inetinfo)	The percentage of time the threads of these process spend using the processor. This counter allows us to eliminate the effect of OS requirement and other external factors. This has to lesser than 70%.
Process\Handle Count (aspnet_wp and inetinfo)	This is the total number of handles open by these process. This has to be on an acceptable value. A value lesser than 10,000 and more than 2000 is acceptable. A value very high can mean there is large request hits being made.
Process\Virtual Bytes	Virtual Bytes is the current size in bytes of the virtual address space the process is using. This has a limit of 2GB unless a 3GB switch is configured on the boot.ini. By default, this is not enabled and using close to 2GB address space can lead to performance considerations.
Memory\Available Mbytes	The amount of physical RAM available in the system. This has be atleast 10-15% of the physical RAM available.
There are many other counters in the system such as the physical, disk and networking that can also be investigated for potential problems. I will not discuss them here.

For a set of SQL Server performance counter catch them here ...