Good to know. Please commit whatever configuration you think is best. I'll test it out on our management nodes. Thanks, Andy
On Tue, Aug 20, 2013 at 3:46 PM, Aaron Coburn <[email protected]> wrote: > 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]> >>> >>> >>> >>> >>> >>> >>> >
