Title:
Bug 73937:(Watson Migration Closure)There's something insidiously incorrect about some info reported by the perfmon (Windows Performance Monitor) counters reported for CF8
| View in TrackerStatus/Resolution/Reason: Closed/Deferred/NotEnoughTime
Reporter/Name(from Bugbase): Charlie Arehart / charlie arehart (Charlie Arehart)
Created: 12/02/2008
Components: Debugging, General
Versions: 9.0
Failure Type: Unspecified
Found In Build/Fixed In Build: 0000 /
Priority/Frequency: Normal / Unknown
Locale/System: English / Platforms All
Vote Count: 1
Problem:
There's something insidiously incorrect about some info reported by the perfmon (Windows Performance Monitor) counters reported for CF8. It's documented, though I doubt most realize it, and it can lead to incorrect conclusions.
The "average request" and "average db" times are not averages over the interval (as many would expect), but instead they are averages for the *last 2 requests* that ran, and indeed only those that completed. That's not quite useless, but it can really be misleading.
Some would presume it's the average over the interval. Others might expect it to include both completed and running requests. But it's neither of those. Could it be changed to do either?
Or if nothing else, could it be reset to 0 at each interval? Here's why I propose this: I was just looking at some data for a server with someone, who had written the CF perfmon stats to a counter log, and it showed the average request time stuck at 6+ seconds for a 5 hour period. They were confused, and I was able to point out that it was due to this problem. Sure enough, we confirmed in the IIS logs that no CFM requests had run in that 5 hour period, and the last ones that ran averaged the 6 seconds.
But if the value was reset at each sample interval, there would never have been this confusion. Really, the average should simply be changed to relect over the interval, and preferable not just those completed but also those running. But short of that, resetting the value each interval is the least we could hope for. Thanks for listening.
Method:
Result:
----------------------------- Additional Watson Details -----------------------------
Watson Bug ID: 3036934
External Customer Info:
External Company:
External Customer Name: charlie arehart
External Customer Email: 03D0090C44723473992015D5
External Test Config: 12/02/2008
Attachments:
Comments: