email article printer friendly get the code more resources

Determine Performance Requirements
Take advantage of the Windows Management Interface to gauge your application’s performance requirements correctly.
by Derek Harmon

June 30, 2005

Technology Toolbox: C#, ASP.NET, ASP.NET 2.0

Developing an enterprise application entails making countless decisions about its design and implementation before it ever enters the production environment in which it will operate. For example, you might wonder whether your application will maintain the required level of service when you deploy it. Or, you might have concerns about its greatest load times or the effects on transactional throughput under stress. How do you know the model you’re using to estimate performance will reflect the reality after deployment?

You can use many different techniques to assist you in determining your application’s performance requirements, but your greatest chance for success comes from a balanced strategy. It’s okay to trust your projections as you create your application, but you also need to verify that they conform to your projections once you deploy the application.

One tool that can help you is the Windows Management Instrumentation (WMI). WMI is an object-oriented system management API based on a standard Common Information Model (CIM) schema supported by several vendors. WMI predates .NET as a large set of scriptable COM objects, highly popular with savvy system developers administering Windows’ myriad knobs and dials. It enables applications to manage systems, monitor applications and IT assets, and present themselves for management and monitoring through instrumentation, which is precisely the sort of lens you can use to take a revealing look at your applications after they’ve been released into their natural habitat.

I’ll show you how to connect your applications to preexisting WMI providers using familiar databinding practices. Accessing the process and thread objects will enable you to measure your application’s processing time, memory management, working set size, and even potentially thread deadlocking situations (see the WMI documentation in the MSDN Library for information on ThreadWaitReason’s values). At first glance, using the .NET Framework for this kind of monitoring looks like a difficult task, but you’ll see that the System.Management namespace makes incorporating this kind of monitoring functionality a cinch.

Before diving into the sample, let’s take a good look at what WMI is and how you can put it to use. In WMI, classes representing manageable hardware or software entities are organized into hierarchical namespaces. Namespaces act as categories that group related classes together and scope names to avoid naming collisions, ensuring that classes in separate namespaces with the same class name don’t conflict. Classes based on the standard CIM schema have well-known namespaces, while vendor-specific WMI objects generally belong to namespaces based on the company and product names.

Classes can have one or more instances. For example, you can partition an application server’s disk so it can host multiple applications. Partitions comprise a class with common characteristics, but each individual partition is a separate instance. Instances can expose properties that WMI clients can query, methods that WMI clients can invoke to manage the instance, and events that WMI clients subscribe to in order to receive notifications when something of interest happens.