G
Guest
Hi...
I've been reading some of the msdn pages on old-style custom performance
counters and the .Net framework System.Diagnostics.PerformanceCounter, and
it's a pretty stark contrast.
All of the older, unmanaged code documentation I've found says "here are
some registry entries, here are a few interfaces you have to implement,
everything else is up to you." Interprocess communication, data allocation,
management, etc are "left to an exercise to the user." Basically, it seems a
very user-unfriendly class of problem.
Contrasted to the System.Diagnostics.PerformanceCounter documentation I've
seen, where absolutely everything seems to be covered, I wonder was there
anything ever inbetween? Were there ever ATL or MFC classes to handle things
like process interop?
I come to the question because we're trying to upgrade an old C++ isapi
filter from IIS 5 use to IIS 6 compatibility. Our ISAPI filter kept stats
and the old iis process model made that easy, since all requests went through
the filter from the central inetinfo process. Now that IIS 6 puts the
filters on each worker process, we need some way to aggregate the statistics.
Since it's an old, unmanaged c++ filter, I was looking at how to implement
performance counters the old way and potentially centralize the stats that
way, but the documentation basically said "abandon all hope, ye who enter
here".
Looking at the .Net framework version of same, however, it seems almost too
good to be true. Simple class interface that handles all process interop.
Is that built on top of some ATL classes I didn't find? Is it really going
to work interprocess?
The other thing that wasn't clear from the Framework PerformanceCounter
documentation was about the lifetime of any given counter - if I do a new
PerformanceCounter () in all 4 IIS worker processes, for example, when does
that performance counter disappear from Perfmon? When the last instance of
the class goes out of scope for the last IIS worker process?
Thanks
_mark
I've been reading some of the msdn pages on old-style custom performance
counters and the .Net framework System.Diagnostics.PerformanceCounter, and
it's a pretty stark contrast.
All of the older, unmanaged code documentation I've found says "here are
some registry entries, here are a few interfaces you have to implement,
everything else is up to you." Interprocess communication, data allocation,
management, etc are "left to an exercise to the user." Basically, it seems a
very user-unfriendly class of problem.
Contrasted to the System.Diagnostics.PerformanceCounter documentation I've
seen, where absolutely everything seems to be covered, I wonder was there
anything ever inbetween? Were there ever ATL or MFC classes to handle things
like process interop?
I come to the question because we're trying to upgrade an old C++ isapi
filter from IIS 5 use to IIS 6 compatibility. Our ISAPI filter kept stats
and the old iis process model made that easy, since all requests went through
the filter from the central inetinfo process. Now that IIS 6 puts the
filters on each worker process, we need some way to aggregate the statistics.
Since it's an old, unmanaged c++ filter, I was looking at how to implement
performance counters the old way and potentially centralize the stats that
way, but the documentation basically said "abandon all hope, ye who enter
here".
Looking at the .Net framework version of same, however, it seems almost too
good to be true. Simple class interface that handles all process interop.
Is that built on top of some ATL classes I didn't find? Is it really going
to work interprocess?
The other thing that wasn't clear from the Framework PerformanceCounter
documentation was about the lifetime of any given counter - if I do a new
PerformanceCounter () in all 4 IIS worker processes, for example, when does
that performance counter disappear from Perfmon? When the last instance of
the class goes out of scope for the last IIS worker process?
Thanks
_mark