On Wed, Apr 19, 2006 at 04:47:56AM -0400, Daniel Veillard wrote:
On Tue, Apr 18, 2006 at 11:32:12PM +0100, Daniel P. Berrange wrote:
> 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.
with HTTP and no pipelining of requests it's gonna be hard to improve,
but I'm afraid most of the time was spent in python code interpretation
on the xend side. did you ran top at some point to check ?
Yes, the CPU was highly loaded by both xenstore & xend processes.
> 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.
Well it doesn't exist yet at least on the client side. There is certainly
a number of optimization doable, hard to tell without a first full round
trip to test.
So all options considered it seem virDomainInfo should be defined
once and for all, so if we foresee more informations to be needed this should
be added ASAP (not that network device informations should really be made
part of a different probe call IMHO).
That makes sense - since we can have an arbitrary number of network / disk
adapters registered to the machine, it wouldn't really be feasible to define
storage space in a statically size structured.
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 -=|