I wrote a script [1] to test the variability of these options (just their presence, not their order). Basically, the script builds a query object with a set of required items (VmDiskFileQuery, FileQuery and FolderFileQuery) and one of each of the other params (FloppyImage, IsoImage, VmConfig, VmLog, VmNvram and VmSnapshot). Each unique query is then executed multiple times to find a better average execution time.
I ran this on a host with 60 running VMs, looking for any *.vmx files. For me, with one exception, all options resulted in an average of 2 - 2.5 seconds per query. The exception was the inclusion of VmConfigFileQuery->new(), which changed the speed to about 118 seconds per query. I don't really know why a VmConfigFileQuery slows things down so significantly, but I have had that option commented out for several months in our production system with no ill effects. -Aaron [1] https://gist.github.com/acoburn/6285643 On Aug 20, 2013, at 1:09 PM, Andy Kurth <[email protected]> wrote: > I noticed the same thing on ours. The "remarkably comprehensive" code > is remarkably slow. I played around with commenting some of the > FileQuery objects out before but never committed any updates. The > VmDiskFileQuery impacts performance the most. It can be omitted when > searching for anything other than .vmdk files. It is needed under > some circumstances for .vmdk files because it allows vmdk disk extent > information to be returned which is used in some places. I think > adding an if statement to check if the argument contains /\.vmdk/ > should work. > > I also found that the order of the *FileQuery objects makes a > difference. I think it only uses the first one that matches, so if > VmDiskFileQuery is after FileQuery, the additional disk information is > not returned. > > -Andy > > On Tue, Jul 23, 2013 at 3:49 PM, Aaron Coburn <[email protected]> wrote: >> Hi, Folks, >> In the vSphere_SDK provisioning module, I have noticed that the >> `_get_file_info` subroutine is really slow -- at least it is on my system. >> >> For example, this is called when looking for *.vmx files on the datastore of >> running VMs. I would expect the query to take only a few seconds, but it is >> usually several minutes before the query returns. >> >> I have done some testing and found that the sluggishness is related to the >> 'query' parameter given to the HostDatastoreBrowserSearchSpec constructor. >> That parameter is an array of different types of objects to query. The >> current code appears to be remarkably comprehensive (around lines 2474 - >> 2525 of vSphere_SDK.pm): >> >> query => [ >> VmDiskFileQuery->new(...), >> FileQuery->new(), >> FloppyImageFileQuery->new(), >> FolderFileQuery->new(), >> IsoImageFileQuery->new(), >> VmConfigFileQuery->new(), >> VmLogFileQuery->new(), >> VmNvramFileQuery->new(), >> VmSnapshotFileQuery->new()] >> >> I have found that, by commenting out everything but VmDiskFileQuery, >> FileQuery and FolderFileQuery, I reduce the query time down to a few seconds >> (instead of minutes). Do any of you know why I would want vcld to query all >> of those other object types? >> >> Thanks! >> Aaron C >> >> >> >> -- >> Aaron Coburn >> Academic Technology Services, Amherst College >> [email protected]<mailto:[email protected]> >> >> >> >> >> >> >>
