Using Performance Counters in .NET

Why use performance counters?

I have good logging you say, excellent traceability in my database, if need be I can attach Ants Profiler, I don't need performance counters.  Not true. Every application that runs on a server and serves multiple users should be load tested.  A few definitions first:
Load testing is not using the Performance Analyser in Visual Studio or Ants Profiler.  This is merely looking for memory leaks and bad performance for a single user.  Still good to do, but doesn't replace load testing.
To be able to load test and understand the results you need to be able to measure throughput and the most likely individual performance of specific tasks while the rest of the system is under load.
Performance counters are the easiest way to monitor throughput and performance of a running system in real time.  It could be achieved with logging to files or database, but why bother? Most load testing tools capture performance monitor data and later analysis, and previous test data doesn't pollute later tests.

What else are they good for? 

Even for single user applications performance counters can be a convenient way to measure individual intensive tasks within the application.  Its also a good way to measure if running tasks in parallel is better than not.

Why not, they're easy to use and there's some free stuff

There's a huge array of standard performance counters that come with the OS and with .NET, that are very useful.  Counters to measure processor utilisation, number of logical threads created, memory usage, GC stats, and ASP.Net requests per second, and % of WCF throttles used.  Basically only code that you have written inside your app won't be measured.  Writing your own performance counters is dead easy, and there isn't much code that invades into your source to make it happen. 

var perfCounter = new PerformanceCounter("My App Name", "Counter 1", false);
perfCounter.Increment();

Watching Performance Counters

To view performance counters and watch live data coming through use PerfMon. This is part of Windows OS.

Gotchas:

1. You may need to reboot after installing a performance counter with the OS.  It may appear in the PerfMon list, but no data comes through.  A reboot will likely fix this, it did for me.
2. Admin priviledges will be required to install custom performance counters into the OS and delete them.  This works in code, but isn't a great idea to run / require production apps to use admin credentials.  To update performance counter data the app only needs to be a member of the Performance Log Users Group.
3. There are some random gaps sometimes in the counters, but in my experience never more than a few minutes.

Download my sample code

Other References:

• Code Project Introduction Article
• MSDN Performance Counter Object
• Using Performance Counters Article

Performance Tuning Resources

Old MSDN posts but a lot of this is still useful:

• Chapter 17 — Tuning .NET Application Performance
• Chapter 15 — Measuring .NET Application Performance

Guidance on setting ProcessModel for IIS hosted Web Apps:
http://support.microsoft.com/kb/821268

A word of warning regarding manual GC

I was party to an email conversation discussing manual manipulation of the GC.  Originally the thread was discussing extreme memory and performance management.  Stephen Cohen, Senior Architect at Microsoft added the following response:

A quick word of warning;

Calling the GC is possible but generally not wise. In many scenarios you will find performance drops. Worse yet, the GC is not limited to a single application (unless you are the only application on a device/server). Calling GC might seem good for you but what about any other application that could be impacted?

In my experience wanting to call the GC directly should raise a flag on the application design and set of a deep design review to investigate before implementing a change. With rare exception you can find a way to manage the flow of data, the size of chunks, number of instances, use of critical sections or parallel processing, etc that will remove the need to call the GC.

That said, it can be done but you should allocate a lot of time to test with enough instrumentation that you can both validate a positive result … better performance than the baseline… and confirm no negative side effects.

Manipulating the GC will affect other .NET applications running on the server.

WCF Performance Comparison

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

Diagnosing Performance Issues in .NET Applications using ETW

On the subject of performance, another good article from the December issue of MSDN magazine.

http://msdn.microsoft.com/en-us/magazine/gg490356.aspx

It gives a good summary of GC activity within your application.