2

I have been reading on C# Performance Counters and I was wondering if I should be keeping them in my release build?

I have never encountered an application that has it's own custom performance counters which leads me to think that maybe it is not a good practice.
At the same time having performance counters specifically dedicated to the process of your application should ease troubleshooting of any problems after release.

  • could be useful for a server application – esoterik Jun 26 '18 at 19:16
  • Of course performance counters are a very useful tool to monitor your application which enables other tools like Zabbix to check these counters and alert if necessary or to display the current or history values in aggregated graphs. So yes, if they are necessary to monitor your application, for example because it's a server app, you need them after release because they are part of it. – Tim Schmelter Jun 27 '18 at 9:56
  • @TimSchmelter, ah, thank you! I thought the same but since I have never encountered custom performance counters in other applications I was wondering if, perhaps, there is something I am missing. – J. Doe Jun 27 '18 at 9:57
  • Custom performance counters can be very useful (otherwise, why would you have added them?) The question of whether to include them in a release, however, is for product management; once you include them, your company might be expected to support them too. – John Wu Jul 3 '18 at 17:27
  • Trying to find out if anyone else has done something is not a great way to make decisions. – Robert Harvey Jul 15 '18 at 14:42
0

Short answer: Include them if you truly need them at run-time

All counters are effectively "custom" as the source app creates them as needed. SQL server, IIS and a whole lot of other Microsoft Services use custom performance counters. Even some of the OS generated ones are missing if you disable the feature that triggers them. They are very useful for doing things like monitoring rates of specific events from outside a large pool of threads.

Permissions issues with creating and managing them is the main issue you can encounter if you are not running as admin, or trying to create/remove them will old-school MSI installers for some reason.

They can have a perf impact at high use and they often end up not being monitored by anything if you leave it up to someone else to create the monitoring.

I often include them, but with a config switch to ignore them completely, and I always code it so a failure on counters is non-fatal and does not waste time retrying frequently.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.