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 -=|