|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] xend / xenstored performance & scalability issues
On Thu, Oct 12, 2006 at 03:16:38PM +0100, Daniel P. Berrange wrote:
> I've been trying to track down just why talking to XenD is resulting in so
> much CPU time being comsumed by both xend & xenstored. As a test case, I'm
> running 'virsh dominfo demo' which results in a single HTTP request to
> Xend to fetch domain info, eg 'GET /xend/domains/demo'
>
> [Snip]
>
> 2. Why does XenD create sooo many transactions in XenStored for a read op ?
> Having instrumented Xend it sems that the root cause of the problem is
> the
> xen.xend.xenstore.xstransact class. This alllows one to start a
> transaction,
> do a bunch of reads/writes & then commit the transaction. At the same
> time
> though it has a bunch of static 'convenience' methods for read & write
> which
> will implicitly start & commit a transaction. Well 90% of the code in
> XenD
> seems to be using these 'convenience' methods instead of explicitly
> starting
> a transaction to cover a piece of work - the result is a simple GET
> causes
> 16 transactions ....and an 'xm create' results in 80 transactions. These
> convenience methods are utterly destroying performance.
>
> Clearly we can't address these for 3.0.3, but I think both of these areas need
> serious work in 3.0.4 if we want a scalable control plane in Dom0. Fixing
> the XenD bit looks particularly hard because any single method using the
> convenience xenstored read functions can be called under many different
> contexts, so of which needs transactions, others which don't. It ought to
> be possible to trace back all the calls & make it possible to pass explicit
> xstransct objects into all calls & then kill off the convenience methods.
Yes, we've already committed to fixing this in Xen 3.0.4. The Xen-API preview
tree already has this work underway.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|