- System Monitor Overview
- The Big Three
- Web Service Counters
- ASP.NET Counters
- Conclusion
ASP.NET Counters
If you have any mission-critical ASP.NET applications running on your Web server, these are the counters you would use to monitor application performance. You'll find that there is more than one performance object for ASP.NET. For purposes of this article, only the ASP.NET and ASP.NET Application counters are of any importance based on the example monitoring scenarios explained below.
When monitoring ASP.NET applications, some key things should be looked at to discover any performance penalties that could lead to application, service, or system instability. When an application restarts, it takes time to recompile the application and dependencies. If any application is restarting frequently, check into why this may be happening so that any unnecessary restarts can be prevented. An application typically restarts when modifications are made to any of the application's configuration files, physical or virtual directory paths, files in the bin directory, or security policy; or when the Web service is restarted. Add the Application Restarts counter to investigate this.
The Request Rejected counter is important to determine whether an application is dropping user requests often. Rejecting requests could be due to any number of things that can include peak load times, processor or memory constraints, slow database activity, or excessive request execution time.
To discover what may be causing rejected requests, take a look at the Requests Current, Requests Queued, and Requests Wait Time counters. If the Requests Wait Time and Requests Queued counter values are both high, Application Restarts low and no processor or memory constraints (plenty of resources), it may be safe to assume that the application's request execution time (also likely to be high) could be the result of poor application design. Application design is beyond the scope of this article, but does play an important role in the application's performance.
To really get the lowdown on an application right down to the code level, check out the .NET CLR performance objects. Counters in these objects will reveal how many bytes are in memory heaps, number of managed exceptions thrown by an application, current process assemblies loaded, number of objects garbage collected, and more.