8:30 a.m.
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 :|
8:45 a.m.
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
12:20 p.m.
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 :|
1:32 p.m.
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
4612
days inactive
4733
days old
3 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Jiri Denemark