This article from InformIT's .NET Reference Guide examines three things to be careful of when working with performance counters.
Windows performance counters monitor performance objects such as disk drives, CPU utilization, processes, threads, and memory. Many of these performance objects are included in all versions of Windows. Others are included only with specific applications or parts of the operating system. For example, the .NET runtime and SQL Server both define custom performance counters that monitor values that are unique to those applications. It's important to understand that a performance object is not necessarily a physical piece of hardware or even an operating system concept. For example, you can define a performance counter that reports the number of transactions posted per second in your ASP.NET Web application.
There are a couple of things you need to know when you get started exploring the world of Windows Performance Counters. The conceptual documentation is excellent in that it provides good context and explains very well the ideas behind performance monitoring and the things you can do with it. But after you've digested the conceptual documentation, making sense of the technical documentation can be quite a challenge. There are three things you should be careful of:
- The Windows performance monitoring API is not well designed. Although the .NET Framework classes hide most of the warts and needless complexity, there are still a few places where the legacy API shows through.
- The .NET Framework SDK documentation for the PerformanceCounter and PerformanceCounterCategory classes is based on the Windows Management and Instrumentation (WMI) documentation, which in turn is based on the documentation for the Performance Data Helper library and the original registry-based performance counters. In many cases the .NET documentation is copied verbatim from the badly written PDH library documentation from more than 10 years ago. Even the original registry interface documentation is difficult, which makes me wonder how anybody ever figured out how to use this stuff.
- There is an unfortunate naming conflict between the high-resolution timer (accessible through the QueryPerformanceCounter and QueryPerformanceFrequence API calls as described in the previous section) and the Windows Performance Counter interface. The documentation uses the term "system timer" in most cases to refer to the high-resolution performance counter, but there are cases when it's easy to confuse the two.
I'm not saying that using performance counters is hard -- just that trying to get useful detailed information from the documentation is something of a challenge. Fortunately, the hard part is creating your own counters and writing data to them. Sampling existing counters turns out to be straightforward. Almost.
The .NET SDK documentation has a very good article entitled Introduction to Monitoring Performance Thresholds, which explains the performance counter subsystem in great detail.
You can read more about creating your own performance counters at InformIT.
