views:

803

answers:

1

I'm trying to create a set of custom performance counters to be used by my ASP.NET application. I use the following code to increment the counters:

internal static void Increment(String instanceName, DistributedCacheCounterInstanceType counterInstanceType)
{
    var permission = new PerformanceCounterPermission(PerformanceCounterPermissionAccess.Write, Environment.MachineName, "CounterName");
    permission.Assert();

    var counter = new PerformanceCounter("CategoryName", "CounterName", instanceName, false);
    counter.RawValue++; // Use RawValue++ instead of Increment() to avoid locking
    counter.Close();
}

This works perfectly in unit tests and also in Cassini on my dev box (Vista Business x64)., and I can watch the counters working in Performance Monitor. However, the counters don't seem to register any incrementation in my production environment (Win Server 2003 x64). The counter instances themselves are available, but they all just show "--" for the last/average/minimum/maximum display.

Any ideas as to what I could be doing wrong?

EDIT: Here's a [perhaps somewhat outdated] MSDN article that I used for reference

EDIT 2: I'm using VS 2008/.NET Framework v3.5 SP1, if that makes any difference.

EDIT 3: Just found this article about 32 bit/64 bit app and monitor mismatching, but I'm not sure how it applies to my situation, if at all. Cassini is indeed a 32-bit app, but I had no problem viewing the values on my 64-bit system. On my production server, both the app and the system are 64-bit, but I can't see the values.

EDIT 4: The values are showing up when I run the 32-bit perfmon on the production server. So I suppose now the question is why can't I read the values in the 64-bit perfmon?

EDIT 5: It actually does appear to be working, it was just that I had to restart my instance of perfmon because it was open before the counters were created.

+1  A: 

I read that instantiating a PerformanceCounter is quite resource intensive. Have you thought of caching these in a Session / Application variable?

Also, is it wise to update the counter without locking in a multithreaded ASP.net application?

Patrick

Patrick J Collins
There does appear to be a bit of overhead involved with instantiating my counters, but at this point it isn't enough to require caching.
Daniel Schaffer
And yes, updating without locking in this case is absolutely required because of the performance impact from locking. Better to have slightly inaccurate numbers than exact numbers and horrible performance.
Daniel Schaffer
Also, welcome to SO! :)
Daniel Schaffer