Skip to content
This repository has been archived by the owner on Jan 22, 2022. It is now read-only.

WBEM Flags #25

Open
woanware opened this issue Apr 4, 2017 · 3 comments
Open

WBEM Flags #25

woanware opened this issue Apr 4, 2017 · 3 comments

Comments

@woanware
Copy link

woanware commented Apr 4, 2017

Is it possible to allow for flags when calling ExecQuery e.g. WBEM_FLAG_RETURN_IMMEDIATELY & WBEM_FLAG_FORWARD_ONLY, as this can significantly improve query performance?

@gbrayut
Copy link
Contributor

gbrayut commented Apr 4, 2017

Hmm... would you want to be able to change these flags between calls to ExecQuery? If not, then adding a WBEMQueryFlags uint32 to the SWbemService struct is probably the easiest implementation. You would set the desired flags after calling InitializeSWbemServices and the same flags would be used for all queries. We already use connectServerArgs ...interface{} on both the InitializeSWbemServices and Query functions, so if they do need to be changed between calls we would have to create a new QueryFlags function.

Once we have a way to get the flags, it should be as simple as changing the CallMethod to include the optional parameters:

resultRaw, err := oleutil.CallMethod(service, "ExecQuery", q.query, "WQL", s.WBEMQueryFlags)

@woanware
Copy link
Author

woanware commented Apr 4, 2017

Well the "normal" way of including the flags is when the ExecQuery method is called e.g.

Set colNTLogEvents = objSWbemSvc.ExecQuery ("SELECT * FROM Win32_NTLogEvent", , 
 wbemFlagReturnImmediately + wbemFlagForwardOnly)

Here are some resources that explain the reasoning for the flags:

https://technet.microsoft.com/en-us/library/ee198934.aspx
https://msdn.microsoft.com/en-us/library/aa390880(v=vs.85).aspx

I tried modifying the code myself e.g. added a QueryFast method, when I passed in 16 as the flag value (wbemFlagReturnImmediately), it works, but passing in 32 (wbemFlagForwardOnly), it generates an "unspecified error", same if the combined value of 48 is passed in

@carlpett
Copy link

Picking this up a year later... I implemented this as well, to try out if it resolves the linked issue from wmi_exporter. See the diff here
In order to avoid the "unspecified error" that @woanware got, we cannot access the Count property of the results, so this means not doing the slice capacity optimization later in the function. Not sure how much of a hit this gives yet.
Due to this, I'm unsure how much better performance can be expected. Probably there would need to be some way to stream the results back instead of doing bulk conversion to properly benefit from it.

Still, would be interested to hear what you think!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants