views:

787

answers:

2

I've inherited code that makes numerous remote WMI calls. When I repeatedly pause execution and look at the call-stack it's almost always in a ManagementScope.Connect() call. A new connection seems to be made with each WQL query.

Despite limited trial and error, I haven't found any big wins yet in improving the performance of the WMI calls.

I've tried caching previous results, reusing connections, and avoiding the dreaded "select *". These haven't given me the performance improvements that I'd like. I'm interested to understand the impact of environment on WMI performance, but the code needs to run in a wide variety of environments that are probably beyond my control.

If any, what are the do's and don't's of performance oriented WMI access in .NET?

+2  A: 

Not my area of expertise, but this might be of some help:

WMI: Improving your WMI application performance in fan-out scenario

"In this blog, I will talk about three different ways of connecting to a remote machine using WMI to perform multiple WMI operations, and their performance differences."

David
Thanks for the excellent content. My original post indicated that I did try "reusing connections" like the linked blog post indicates. I did some other experiments and got significant improvements that I plan to write up for everyone's benefit. I suspect that there are certain properties on the .NET objects that when set cause subsequent operations to reconnect. I plan to write these up soon. It does make sense that whatever applies to DCOM WMI access probably also applies to the .NET classes as well. Thanks!
devgeezer
@Devgeezer how did you made your improvements in .NET? Did you wrote an wrapper?
JSC
+1  A: 

Are you making multiple calls to the same machine or many machines? If the latter, have you considered multi-threading?

serialhobbyist
For now it's the same machine; the code is for automated remote installs. The code first determines what dependencies have already been installed, queries the OS (determining things like processor architecture, system directory, program files directory, OS version, etc); it does this to configure the install, then uses WMI to launch and monitor the install. There has been a feature request to enable these to be queued and run parallel (for example 5 at a time). Good suggestion.
devgeezer
Ah-hah. I've done something very similar in vbscript. Mine was both nasty and painful. I wish you well.
serialhobbyist