[libvirt] Horrible performance of virDomainGetInfo()
While investigating the RPC problems I've noticed that we have had a huge performance regression for virDomainGetInfo() due to the change which makes virDomainEndJob() save the XML status file every time it is called. Previous to this change, 2000 calls to virDomainGetInfo() took ~2.5 seconds After this change, 2000 calls to virDomainGetInfo() take 2 *minutes* 45 secs I don't have an answer right now and it shouldnt block the release, but we have todo something to avoid this overhead. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Dec 07, 2011 at 14:30:10 +0000, Daniel P. Berrange wrote:
While investigating the RPC problems I've noticed that we have had a huge performance regression for virDomainGetInfo() due to the change which makes virDomainEndJob() save the XML status file every time it is called.
Previous to this change, 2000 calls to virDomainGetInfo() took ~2.5 seconds
After this change, 2000 calls to virDomainGetInfo() take 2 *minutes* 45 secs
I don't have an answer right now and it shouldnt block the release, but we have todo something to avoid this overhead.
I think we could change job APIs to only save XML status if async job is active since we are currently not really interested in other jobs anyway. Jirka
On Wed, Dec 07, 2011 at 03:45:10PM +0100, Jiri Denemark wrote:
On Wed, Dec 07, 2011 at 14:30:10 +0000, Daniel P. Berrange wrote:
While investigating the RPC problems I've noticed that we have had a huge performance regression for virDomainGetInfo() due to the change which makes virDomainEndJob() save the XML status file every time it is called.
Previous to this change, 2000 calls to virDomainGetInfo() took ~2.5 seconds
After this change, 2000 calls to virDomainGetInfo() take 2 *minutes* 45 secs
I don't have an answer right now and it shouldnt block the release, but we have todo something to avoid this overhead.
I think we could change job APIs to only save XML status if async job is active since we are currently not really interested in other jobs anyway.
Ok, that sounds like a reasonable idea. Could you cook up a patch for that. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Dec 07, 2011 at 18:20:16 +0000, Daniel P. Berrange wrote:
On Wed, Dec 07, 2011 at 03:45:10PM +0100, Jiri Denemark wrote:
On Wed, Dec 07, 2011 at 14:30:10 +0000, Daniel P. Berrange wrote:
While investigating the RPC problems I've noticed that we have had a huge performance regression for virDomainGetInfo() due to the change which makes virDomainEndJob() save the XML status file every time it is called.
Previous to this change, 2000 calls to virDomainGetInfo() took ~2.5 seconds
After this change, 2000 calls to virDomainGetInfo() take 2 *minutes* 45 secs
I don't have an answer right now and it shouldnt block the release, but we have todo something to avoid this overhead.
I think we could change job APIs to only save XML status if async job is active since we are currently not really interested in other jobs anyway.
Ok, that sounds like a reasonable idea. Could you cook up a patch for that.
Oops, this completely slipped my mind. The fix seems to be a bit more complicated since async job is not the only one we are interested in. I'll send it to the list next week once I test that it didn't break anything. Jirka
participants (2)
-
Daniel P. Berrange -
Jiri Denemark