Scott Colestock broke the news earlier today about his QuickCounters project. QuickCounters is a great library (and associated tools) for instrumenting applications using Windows NT performance counters in a simple way. It not only does the bulk of the work of dealing with the performance counter API (both for deployment as well as runtime), but it also has a simple and easy to use UI Client you can use to read the performance counters for your application.
A while ago I mentioned I was experimenting with creating custom Windows Communication Foundation extensions to instrument WCF services. A little after that, Scott approached me and told me about QuickCounters and I immediately recognized that his stuff was way better than the very basic stuff I had, and agreed to modify my extensions to build on top of QuickCounters. Thanks to the very easy to use API in QC, it was a breeze to do. Scott also allowed me to integrate my extensions into the QuickCounters project in CodePlex, in the QuickCounters.Wcf assembly, so it should be available to anyone wanting to use them.
Instrumenting WCF Services
The WCF extensions are very simple right now. What we have is a custom service behavior which injects an IDispatchMessageInspector, which internally calls the QC API to instrument the service calls. I've mentioned in the past why I switched from my original implementation using an IParameterInspector implementation.
Applying the extensions can be done either through code or through configuration. Code-based instrumentation is done by applying the [InstrumentedService] attribute to your WCF service implementation class, like this:
public class VoucherService : IVoucherService
If you want to instrument the service through configuration, you can do this like this:
<add name="instrumentedService" type="QuickCounters.Wcf.Configuration.InstrumentedServiceElement,
QuickCounters.Wcf, Version=188.8.131.52, Culture=neutral, PublicKeyToken=401c7ea1618cbd56"
<behavior name="ServiceBehaviors" >
If you've read the project documentation, you'll know that besides adding the attribute/behavior in WCF to enable the instrumentation, you also need to configure your performance counters through QuickCounters. For this, you need a simple metadata XML file that tells QuickCounters what your service is called and what types of requests it contains. While the schema is extremely simple, it can be cumbersome to create.
Fortunately, creating the metadata XML is trivial to do using tools. The QuickCounters project offers two alternatives for this: The first one is a standalone command line tool called QCFromWSDL.exe, which will use your service WSDL file and generate the corresponding QC XML file.
The second one, however, is far more interesting, and it's the result of all the work I've talked about before on publishing arbitrary metadata endpoints for a WCF Service. So here's how it works. The QuickCounters.Wcf behavior contains an enableHttpGet boolean property. If it is set to true, and your service is exposed via HTTP, then the behavior will automatically inject a new endpoint at the
So, for example, if your service is published at the http://localhost/VoucherService/VoucherService.svc URL, and the value of the "address" property for your InstrumentedService behavior/attribute is set to the value "qc", this new endpoint will be published at http://localhost/VouchedService/VoucherService.svc/qc.
[Note: All this properties are available both for the code-based attribute as well as the config file tag].
When you navigate to this endpoint using your browser (or the QuickCounters tooling), you'll get an auto-generated QuickCounters XML metadata file you can use right away.
Oh and by the way, the "ApplicationName" and "Service" properties allow you to override the InstrumentedApplication/Name and Component/Name fields in the generated XML.
I hope people find these extensions useful. The QuickCounters library is a great tool that I will be using quite a bit in future projects, and I rather like using it alongside with the WCF extensions over (or rather as a complement to) the built-in performance instrumentation in WCF.
I will also be extending this to support new use cases. In particular, I hope to add a new behavior to instrument client-side proxies, and eventually hope to be able to instrument callback contracts on the server as well. If you find any problems, bugs or have any suggestions, we'd sure appreciate them as we hope to make this as useful and trouble-free as possible! Enjoy!