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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
>> 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

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]