[Libvir] Add a timestamp to virDomainInfo ?

[Daniel P. Berrange]

On Thu, Apr 13, 2006 at 05:57:13PM -0400, Daniel Veillard wrote:
> On Thu, Apr 13, 2006 at 10:37:17PM +0100, Daniel P. Berrange wrote:
> > 
> > I've not really got any formal data on it at this time - it was just a random
> > afternoon thought. I'll see if there's any useful way to get some data on
> > the effects.
> 
>   if running as root locally with Xen, then getting the data is a simple
> hypercall, I would expect that to be nearly as fast as a gettimeofday(),
> and this won't increase precision. In the case of a non-root local process
> with an HTTP request to xend the time spent could potentially be quite large
> actually not bounded at all due to potential I/O, the quality of the 
> data extracted then will be poor due to the tme of acquisition, would 
> that be worth it ? The last corner case is a remote monitoring, and there the
> time spent is most likely to be due to network round trip, which in general
> is approximated by taking the medium time between emission and reception
> the time to do the 2 gettimeofday() are probably neglectible.
> So in those 3 kind of extreme scenario it's a bit unclear how adding the
> timestamp to the data would really help, except maybe as a convenience to
> the user layer.
>   Actually getting some data about the costs of doing the call as root
> though the hypervisor versus the xend HTTP RPC would be an interesting
> datapoint in itself, I initially wanted to hack virsh to extract 
> statistics about this but never took the time to do it :-)

So I wrote a crude micro-benchmark to just analyse the cost of calling 
virDomainGetInfo under different circumstances. Basically the loop
does 10,000 calls to the method & reports min,max,avg time. Like I said,
the test is crude, but the results give a picture which is consistent
with what I'm seeing in practice (ie the applet consume 5-10% CPU just
updating domain stats once a second).

All times are milliseconds in the following results..

1. Running the test as root, so virDomainGetINfo does a hypercall:

    Total 239.397094726562
    Avg: 0.0239397094726563
    Min: 0.021484375
    Max: 0.548974609375

2. Running the test unprivileged, so calls go via XenD/XenStoreD:

    Total: 71546.1286621094
    Avg: 7.15461286621094
    Min: 6.1657958984375
    Max: 45.3959228515625

So, as to be expected, the XenD/XenStoreD approach has significantly higher
overhead that direct HV calls. The question is, is a x350 overhead for 
unprivileged user's acceptable / can it be improved to just one order of
magnitude worse.

As a proof of concept, I wrote a daemon wich exposes the APIs from libvirt
as a DBus service, then adapted the test case to call the DBus service
rather than libvirt directly.

3. Running the DBus service as root, so libvirt can make HV calls

    Total: 11280.2186035156
    Avg: 1.12802186035156
    Min: 1.0397216796875
    Max: 6.5512939453125

So this basic DBus service (written in Perl BTW) is approx x50 overhead 
compared to HV calls, significantly better than the existing HTTP/SExpr
RPC method. It'll be interesting to see how the new XML-RPC method compares
in performance.

Getting back to the original point of my first mail, while there is definitely
a difference between calls via HV and those via XenD/XenStore, but even the worst
case is only  45 milliseconds - with the applet taking measurements once per 
second it looks like CPU utilization calculations will be accurate enough. So
there is no pressing need to add a timestamp to virDomainInfo.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|