[libvirt] [PATCH] Refresh QEMU driver caps in getCapabilities

Cole Robinson crobinso at redhat.com
Tue Apr 28 21:35:51 UTC 2009


On 04/28/2009 05:13 PM, Gerrit Slomma wrote:
> Cole Robinson schrieb:
>> (...)
>>
>> To test the performance impact, I used a simple python script:
>>
>> import libvirt
>> conn = libvirt.open("qemu:///system")
>> for i in range(0, 30):
>>     conn.getCapabilities()
>>
>> The time difference was on average .02 seconds slower, which I think is
>> negligible.
>>
>> If at somepoint in the future, capabilities generation becomes smarter
>> (searching PATH emulators, scraping device list output, etc.) it might
>> be worth re-checking the time impact. But for now it doesn't seem to be
>> an issue.
>>
>> Thanks,
>> Cole
>>  
>> ------------------------------------------------------------------------
>>
>> -- 
>> Libvir-list mailing list
>> Libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
> 
> .02 seconds slower compared to what time?
> Without a given base this result doesn't say much.
> It wouldn't matter if the execution-time was 3600 seconds prior to the
> change but would be a realt bottleneck if it was 0.01 seconds prior to
> the change.

The results were around .4 seconds real time. I didn't think that info
was particularly relevant in this case though, since the python script
is fetching the capabilities 30 times.

Rereading my original email again, I was pretty unclear that the .02
time difference was for calling capabilities all 30 times, so the real
impact would only be .02/30 = .00067 seconds per capabilities call,
which is negligible no matter what the % slow down.

> I know a virsh capabilities is not that slow, but i haven't clocked it
> up to now but have done so now that i have read your post and got this
> on my machine:
> 
> rr016# time virsh capabilities
> (...)
> real    0m0.005s
> user    0m0.001s
> sys     0m0.002s
>

Just calling virsh capabilities isn't the best metric, since there will
be overhead in driver opening, possibly authentication, actually
printing the result, etc. Not that my method is perfect either, but
incurs less overhead than virsh.

Thanks,
Cole




More information about the libvir-list mailing list