Re: [Xen-devel] xm speed

[Brian Wolfe <ahzz@xxxxxxxxxxx>]

May I make a suggestion? 

I've worked with daemons of my own in the past and found it very usefull
and faster for third party development to use a light XML parser library
to handle the control interface parsing. I'd think that going with XML
structures instead of flat text/html/binary would make it easy to self
document the interface and command/response data structures (standard
XML argument).  I wouldn't even bother with HTTP at all. Just accept an
XML structure that describes the task, or list of tasks that need to be
done. then return a simple xml structure with results and error codes so
we know what commands suceeded and which one it failed at. Could also
tag commands as continue on fail for batches such as gathering stats on
each domain.

This would make it far easier for poeple to write their own control
interfaces and just interact with xend (meaning, I'd have an easier time
writing a controller process for the cluster of xen boxes vs rewriting
xend ;) ).

If you like this idea I'd be VERY interested in helping to work on it.
Won't matter to me if it's interpreted language like
perl/python/ruby/etc or if it was in C/C++. Either works for me (just
not too experienced in python.)

This is the approach that I was taking with the replacement xend I
started for xen 1.2 (which I've abandoned until 2.0 is released, and it
will be restarted from scratch). A master and slave master node daemons
that talked to the xen node daemons via the network to track each xen
servers vhosts/loads/etc, sort of like a cluster manager. I do believe
that we should attempt to make it as easy as possible to hook into the
xen system either at the libxc or xend levels. 

Thanks for listening!

Brian


On Fri, 2004-09-10 at 07:55, Ian Pratt wrote:
> > I'm waiting about 2 seconds from typing 'xm list' and for something to
> > appear. Is this normal? The machine is fairly old, it's a Compaq
> > Proliant 1600 with a single CPU running at 350Mhz. It's hardware RAID
> > but that is pretty slow too.
> 
> If you look at the output of 'xm list' does the CPU time consumed
> by dom0 go up by 2s every time?
> 
> Is dom0 competing for CPU0 with a bunch of other busy domains?
> 
> On our 2.4GHz Xeon machines, I've noticed that running 'xm list'
> causes the amount of CPU consumed by dom0 to go up by around
> 100ms, which is quite a staggering amount given what it's
> actually doing. Python isn't the most efficient of languages, and
> we are doing a HTTP RPC between xm and xend, but this level of
> resource usage has always rather surprised me. 
> 
> I guess we could use one of the python profiling tools to find
> out where the overhead is. Since this is all 'control plane' we
> haven't made any effort to make it efficient and have
> concentrated on flexibility. It it starts becoming a bottleneck
> it may be necessary to selectively recode bits in C.
> 
> Ian
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel