[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
On Mon, 2005-01-24 at 10:55, Jared Rhine wrote: > > > Again, this is not an issue of esthetics, it's an issue of measured > > > performance. > > > > Where's the performance issue? > > I think Ron was suggesting that the dual handoff of the data between the > UDP listener and the TCP listener would be foolish and avoidable and > inarguably is a measurable throughput degredation over a direct TCP > processing loop. You're not going to have a direct listener though on TCP. I think you mean unix domain sockets too instead of UDP. The current message passing architecture assumes the messages are originating from the native architecture. They do not take into account things like endianness into consideration. They certainly don't security into account at all. To export a proper TCP interface requires a higher level protocol. The TCP interface will have to do a certain amount of work to take these things into account. I think we all agree that we need a TCP interface. The only real question is whether you export a lower level protocol interface via something like domain sockets. Domain sockets are extremely fast on most platforms (usually reducing to something like a memcpy). Considering the message size here I do not think you can make a performance argument for having a TCP daemon go through a domain socket. If we agree that we need a higher level protocol for TCP, then it becomes pretty apparently that there's going to be desire for multiple protocols. Maybe a less security conscious protocol for isolated clusters (like xcs implements right now) verses a more hardened protocol for enterprise usage. Using multiple daemons here becomes a no-brainer. You just start the appropriate daemon for whatever protocol you wish to export. Properly architected, multi daemons could even be run simultaneously to support multiple sets of control tools. > Ron, is your performance concern because large clusters need to pass a > very high volume of control messages? For any low-volume situation, > this unix domain/TCP argument is a non-issue, mostly? I have a feeling that the concern is that there's a general fear that more daemons == more resource usage == more administrative overhead. I don't think this is true though. I think it simply depends on how things are architected. -- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: aliguori@xxxxxxxxxx Phone: (512) 838-1208 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |