indows lets you monitor a large number of internal statistics. Most people only see them in the Performance Monitor utility. This is fine if all you need is to look at graphs, but to fully study and analyze the information, you’ll need to get at the raw data. Windows gives you access to the raw data, but only through a cumbersome C API. However, with the proper application of a few C++ techniques, you can make the whole process much simpler.
Working with (and Wrapping) Queries
At the lowest level, the structures used are defined in the Platform SDK header
The structure at the heart of performance monitoring is the HQUERY. It is initialized with the API function PdhOpenQuery(), and closed out with PdhCloseQuery(). Clearly this calls for a wrapper class, which I’ll call Query, with a constructor and destructor handling these tasks. The main purpose for a HQUERY is to manage a number of HCOUNTER structures. They are attached to a HQUERY by calling PdhAddCounter(). Add a member function to Query to attach them. Also add a cast to access the underlying HQUERY, and you have a functioning minimal interface for Query (see Listing 1). It’s fairly simple, and if that were all, I might not have even bothered with the C++ wrapper. But there is more. The next piece is the HCOUNTER structure. Every value you wish to monitor gets one HCOUNTER, and all of them are managed by the HQUERY (or, by the Query class). However, wrapping the HCOUNTER poses a special challenge. You create it, but it must be filled by another process–the one that’s being monitored. This means it needs to exist in Shared Global Memory. You never have a HCOUNTER; you have to use a pointer to an HCOUNTER, and allocate the HCOUNTER with GlobalAlloc(). This greatly complicates making a wrapper class.
At first, you might decide to store a HCOUNTER* as the class’s sole data member, calling GlobalAlloc in the constructor and GlobalFree in the destructor. This method is problematic. You’ll need to write a copy constructor as well, but how should that work? Normally, the copy constructor would allocate a new block of memory and copy the data from one to the other. The problem is that this block, by its very nature, is shared. Some other program is both looking at and writing to it. If you allocate a new block, they may be identical for a moment, but the other process will still be writing to the first one.
Another solution is to have just one memory block, and simply pass a pointer around to it. In this case, you can’t have the destructor free the block. For example, if you were to return such an object from a function (which is something you will want to do), you create a new object by calling the copy constructor (copying just the pointer), and then the original object goes out of scope as the function ends (and its destructor is called, freeing the block). But removing the allocation/deallocation from the constructor/destructor leaves you with the wrapper class doing nothing at all. It was supposed to make working with a HCOUNTER simpler! You need a reference counted pointer to keep track of how many pointers to the block are being used, and to automatically delete the block only after all references to it are destroyed.
Smart Pointers
Pointer classes like this are commonly referred to as “smart pointers”. The best known is auto_ptr, which is now part of the Standard C++ Library. Unfortunately, this leads some to believe that auto_ptr is right for every situation that calls for a smart pointer, but this isn’t so. Auto_ptr has a very specific use, but this is not it.
Writing a reference counted pointer class is not particularly difficult, and is described in a number of reference books. You don’t have to worry about this, however, as the work is already done for you by the good folks at Boost.org. Boost is a public organization developing an open source C++ library of commonly used tools.
One of the very first things added to Boost was the Smart Pointer library, which includes shared_ptr<>. Considering it’s general utility, and growing use, it has a very good chance of being added to the Standard Library when the next C++ Standard is complete (circa 2005 or so). The more it’s used now, the better the chances it has of becoming part of the Standard.Shared_ptr is a simple “drop-in” class to handle reference counting. Just say “boost::shared_ptr
struct GlobalCounter{ void * operator new(size_t ) { return GlobalAlloc(GPTR,sizeof(HCOUNTER)); } void operator delete(void * ptr) { GlobalFree(ptr); } HCOUNTER* handle() { return (HCOUNTER*) this; }};
When new is called, it allocates enough space from global memory, and frees it on delete. I also added a member function called handle() to get a pointer to the raw memory itself. The version shown here is just for presentation; the version given in the complete source listing is templatized to allow reuse (see Listing 2).
Now that all the pieces are in place, you can finally create a wrapper for a HCOUNTER struct which will allow you to treat it just like any other object.
#include "boost/smart_ptr.hpp"struct Counter : public boost::shared_ptr< GlobalCounter > { Counter () : boost::shared_ptr< GlobalCounter > (new GlobalCounter ) {} operator HCOUNTER *() { return get()->handle(); }};
As with GlobalCounter, the full version of the inline code is in the complete source (see Listing 3).
Finally, you have to deal with the essence of performance counters. You have one or more Counter objects, which are created and managed by a Query object. So, request a new counter by adding it to the Query object, which provides it with a Counter object. To determine what values the counter totals, ask the Query object to Collect the data. The values will appear in the Counter objects.
Query hQuery;Counter counter = hQuery.AddCounter(_T("\TCP\Connections Established"));hQuery.Collect();
The string passed to AddCounter describes the value you want to monitor. They follow the basic format “\MachinePerfObject(ParentInstance/ObjectInstance#InstanceIndex)Counter.” Some of those pieces are optional. For example, in the above code, you have TCPConnections Established”, which has just the PerfObject and Counter parts. Similarly, you could have \Mach02Process(Explorer)\% Processor Time to find the processor time used by Explorer.exe on a remote PC called “Mach02.”
A full list of the monitored values isn’t possible since the system is extensible to user-defined counters. However, you can use other functions in the PDH to get a partial list. These functions can be found by looking at the options in PerfMon.
Now that you have the value you want in the Counter, you need to get it out. This poses a new problem, as the format of the count varies depending on what’s being counted. Sometimes it’s a long and sometimes it a double, or LONGLONG, or a string. And to make things even more complicated, you have to ask the OS to convert the counter into any of those forms. I’ve added a few more member functions to Counter, to simplify this. Each comes in two variations: One to return the value as the native type (Counter::asDouble for example), and another to return the value converted to a std::string (Counter:: asLongString). If an error occurs, say, when you ask for the value in an incompatible type, the string functions return “(error)” while the native type functions throw an exception.
