| Performance monitoring | |
|
Overview Features Screenshots Pricing Download Order Samples Support Other products |
Prof's Performance Monitoring Components allow you to add your own customized high performance counters to your applications, allowing for the capture and analysis of performance data that can be used to determine system bottlenecks and fine-tune system and application performance. These performance counters are accessible by any tool that can also display the built-in Windows counters. The components have been specifically designed with simplicity in mind so you can just drop the components onto your application's form or data module and start using them right away, without the inconvenience traditionally associated with performance monitoring. Architecture Providing performance data is achieved almost entirely by using just two logical entities - performance objects and performance counters. A performance object is an entity for which performance data is available and each one defines its own set of performance counters, which define the type of data that is available for that performance object. Prof's Components provides the TPCPerfObject class, which represents a single performance object, and the various subclasses of TPCPerfCustomCounter, which represent the different types of performance counters. Performance objects and their counters need to be registered on the local machine on which the performance data is to be collected before they can be used to capture the data. Once an object and its counters have been registered, its definitions will persist in the registry until they have been unregistered. Collection and analysis of performance data can be achieved through either the Windows Performance Monitor (perfmon.exe) or custom performance-monitoring applications. Performance Monitor uses the Performance Data Helper (PDH) interface exclusively, whilst custom applications can choose from the registry interface, PDH (through either the registry or WMI), and pure WMI. The raw performance data is collected at (typically) regular intervals by a performance monitoring application, where it is "cooked" before being displayed to the user. Each counter type has its own "recipe" formula that is used to cook the raw data. The typical recipe for each counter is explained in the specific counter's help documentation. The TPCPerfCounter and TPCPerfTimer counters' recipes typically depend on the difference between the current and the last sample's performance data, while the TPCPerfLevel counter's recipe typically depends only on the current sample's performance data. It is important to note that the performance monitoring application that collects the data is entirely responsible for the cooking the data. Prof's Components provides performance data by means of a performance extension DLL, which needs to be installed to the Windows\System32 folder before performance data can be collected. The WMI AutoDiscovery/AutoPurge (ADAP) process transfers performance counter objects into Win32_PerfRawData and Win32_PerfFormattedData derived classes in the WMI repository. Example 1: Analysis Of A Built-In Windows Performance Object Consider the scenario in which a dual processor machine needs to be monitored for the percentage of time that each processor is idle. An analysis of the situation reveals one performance object with one performance counter. The processor would be the performance object and the percentage of time that each processor is idle would be the performance counter. As we are dealing with a dual processor machine, there are two instances of the performance object. In summary, we would have two instances of a performance object "Processor", called "0" and "1", which both provide performance data for "% Idle Time". If we were to represent this object using Prof's Components, we would need to create one multiple instancing TPCPerfObject, with a TPCPerfTimer as its sole counter. Every time an instance of the processor performance object became idle its timer would be started, and every time it began work again its timer would be stopped. Coupled with information about the duration of the sample interval, a performance data collector such as Performance Monitor would be able to calculate the percentage of idle time spent by each processor, using the timer's recipe. Additionally, whenever a performance object has multiple instances, another instance is implicitly included by the performance library, which measures the total percentage of idle time for both processors. This instance is named "_Total". Example 2: Creating Your Own Customized Performance Object Consider the scenario in which an application needs to be monitored for the number of Windows messages that arrive in its message queue every second. The performance object in this case would be "Windows Messages", and the performance counter would be "Messages/sec". If we wanted to monitor the messages regardless of their source, we could create a performance object with a single instance. However, if we wanted to collect and analyze messages from the mouse and the keyboard separately, we would need a performance object with multiple instances. These instances could be named "Mouse" and "Keyboard" respectively. It might also make sense to have an "Other" instance to collect the messages that weren't generated by either the mouse or the keyboard. Every time that a Windows message arrives in the application's message queue, the performance counter for the appropriate instance would be incremented. When the Performance Monitor application samples the performance counter's data, it will first cook the data according to its recipe, then the resulting data will be displayed in the correct units. You can see this for yourself by loading the Windows Messages sample that is bundled with the Prof's Performance Monitoring Components, and moving the mouse over the form to generate Windows messages. Components
|
