On Tue, Apr 18, 2006 at 11:32:12PM +0100, Daniel P. Berrange wrote: [ data snipped] cool, thanks for the data. This confirms my expectations too. > 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 ? > 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. 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. > 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. okay. Still this raised the interesting point of virDomainInfo size, and future ABI compatibility. I wanted to avoid returning memory allocated by the library, so the client allocate that structure most likely on the stack, and we really can't change its size in the future. We could try to make it future proof by adding extra padding, but then what would be returned would be libvirt version dependant which is not a good thing either. Last possibility is to add a version info to virDomainInfo itself, but that messy too what happen if the client code forget to initialize the value, there is a risk of random crash. 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). There is also a cost tradeoff, if informations are pulled from an RPC it's best to minimize the round-trip and extract as much as possible in one call, while if using HV call, the danger is to not be able to complete the virDomainInfo and requiring some more costly operations. In a nutshell I just hope the current set of data in virDomainInfo is sufficient for applications and we won't need to extend it. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/