Here are few performance monitor counters for Web Server
| Counter Name | Collection Notes | Comments |
| .NET CLR Loading :Bytes in Loader Heap | Make sure this for aspnet_wp | The number of bytes committed by the class loader across all AppDomains. This counter should reach a steady state. If this counter is continuously increasing, monitor the "Current Assemblies" counter. There may be too many assemblies loaded per AppDomain. |
| .NET CLR Memory: % Time in GC | Make sure this for aspnet_wp | The percentage of time spent performing the last garbage collection. An average value of 5% or less would be considered healthy, but spikes larger than this are not uncommon. Note that all threads are suspended during a garbage collection |
| .NET CLR Memory -> # Gen 0 Collections | Make sure this for aspnet_wp | These three GC counters provide insight on the efficiancy of the GC. Basically Gen 0 should be the highest. Gen 1 should be at least 1/2 of Gen 0's count and usually more like 10%. Gen 2 should be the lowest. It should be about 1/2 of Gen 1 and the less the better. As we move up through the generations GC operations are more expensive so we want to watch and use these to determine if we need to examine allocation patterns. |
| .NET CLR Memory -> # Gen 1 Collections | Make sure this for aspnet_wp |
|
| .NET CLR Memory -> # Gen 2 Collections | Make sure this for aspnet_wp |
|
| .NET CLR Memory -> # Bytes in all Heaps | Make sure this for aspnet_wp | The number of bytes that are allocated currently by .NET. This should have peaks and valleys. A steady climb can indicate a memory leak or memory usage issue. |
| .NET CLR Exceptions -> # of Exceps Thrown | Make sure this for aspnet_wp | Exceptions are a very expensive thing yet very powerful thing. They can be very helpful but should be an "exceptional" occurance. Essentially the could should be low and not constantly climbing. If there is an exception that is occuring on every call to some function that function should be analyzed to add validation logic to avoid the exception if possible. If it has been identified that there are too many exceptions a debugger should be used to track down the type of exception that is causing the problem. |
| ASP.NET: Requests Queued |
| The number of requests currently queued. When running on IIS 5.0, there is a queue between inetinfo and aspnet_wp, and there is one queue for each virtual directory. |
| ASP.NET: Worker Processes Running |
| The current number of aspnet_wp worker processes. For a short period of time, a new worker process and the worker process that is being replaced may coexist. Although rare, sometimes processes deadlock while they are exiting. If you suspect this, consider using a tool to monitor the number of instances of the worker process. Alternatively, the Memory\Available Mbytes performance counter can be used, since these hanging processes will consume memory. |
| ASP.NET: Application Restarts | If this counter is going up you should also monitor: .NET CLR Loading -> Total AppDomains and Current AppDomains. If current is growing line with Total then you know that you have and issue where the AppDomain is not getting unloaded on Application Restart and this can cause a leak. | When the ASP.NET Application Restarts all of the assemblies have to be unloaded, reloaded, reJITed, and all of the application memory objects must be reloaded. Restarts typicall occur when editing the Web.Config or some other change to application filies. A restart every once in a while is not a problem, but if they happen frequently this can become a performance issue. |
| ASP.NET: Worker Process Restarts |
| This is related to the number of Application Restarts and has similar performance implications. However the cause is typically things like the process crashing. This can also occur when hitting memory, queue limit, or timeout thresholds. |
| Process: % Processor Time. | Make sure this for aspnet_wp | The percentage of time the threads of this process spend using the processors. Threshold: 70%. Values greater than this for extended periods of time indicate a need to purchase hardware or optimize your application. |
| Process:Thread Count | Make sure this for aspnet_wp | The number of threads active in this process. Thread count often increases when the load is too high. |
| Process -> Private Bytes | Make sure this for aspnet_wp | If the application is completely managed this should grow in parrellel to # Bytes in All Heaps. If this counter is growing consitently and # Bytes in All Heaps is level that is an indication that there is an unmanaged mem leak. |
| Process -> Virtual Bytes | Make sure this for aspnet_wp | Most application run out of addressable memory before they run into any physical memory limitation so this counter is very imporant to monitor because if it goes above 1.2 GB the chances of an out of memory condition are VERY high. |
| Process -> Handle Count | Make sure this for aspnet_wp | The OS has a finite amount of handles for things like Files, Events and other OS objects so it is important in a web scenario to make sure that you are not leaking handles these. |
| Memory -> Available MBytes |
| Import when considering how often we are paging. This count also can impact how frequently the GC needs to run |
| Web Service: Current Connections |
| A threshold for this counter is dependent upon many variables, such as the type of requests (ISAPI, CGI, static HTML, and so on), CPU utilization, and so on. A threshold should be developed through experience. |
| Web Service: Total Method Requests/sec |
| Used primarily as a metric for diagnosing performance issues. It can be interesting to compare this with "ASP.NET Applications\Requests/sec" and "Web Service\ISAPI Extension Requests/sec" in order to see the percentage of static pages served versus pages rendered by aspnet_isapi.dll. |
| Web Service: ISAPI Extension Requests/sec |
| Used primarily as a metric for diagnosing performance issues. It can be interesting to compare this with "ASP.NET Applications\Requests/sec" and "Web Service\Total Method Requests/sec." Note that this includes requests to all ISAPI extensions, not just aspnet_isapi.dll. |
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
