11

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?

devgeezer
  • 4,159
  • 1
  • 20
  • 26
  • Are you making multiple calls to the same machine or many machines? If the latter, have you considered multi-threading? – serialhobbyist Jul 01 '09 at 12:44
  • 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 Jul 06 '09 at 14:13
  • Ah-hah. I've done something very similar in vbscript. Mine was both nasty and painful. I wish you well. – serialhobbyist Jul 07 '09 at 15:08

1 Answers1

6

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
  • 1,167
  • 15
  • 24
  • 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 Jul 06 '09 at 14:04
  • 2
    @Devgeezer how did you made your improvements in .NET? Did you wrote an wrapper? – JSC Aug 31 '10 at 15:56
  • Onto other things at work but here's what I recall: WMI code I inherited was making lots of short redundant WMI connections. Most of time was spent connecting, making one call against a WMI class, disconnecting and repeating. Try to reuse the connections, even query results when reasonable as well as the other management-scope items where possible. Remember to dispose when you no longer need them. Taking a caching approach, our process went from 10+ minutes to about 2.5 minutes - after which WMI no longer was the longest-running part of the process. – devgeezer Dec 07 '11 at 19:22