Dnia 2008-06-05, czw o godzinie 16:18 +0200, Jean de Largentaye pisze: > Well, I think it is rather ironic, because the original design > specifically went for multiple executables that could be able to > distribute the load on different networked servers. Wasn't it one of > the reasons of the redesign from jabberd14?
IIRC jabberd2 started as an experiment of developing each component separately, that was later joined as one project under jabberd2 label sharing and mixing subcomponents. Precursor of c2s component, jadc2s is even still alive today, as a better replacement for internal jabberd14 c2s component. Joining components in one binary would still allow running each separately. Nothing stops deployment from running only one component in one process - similarly to how it is today. > I realize the question is whether this use-case is efficient, and > whether your bottleneck is socket-IPC or CPU load. You'll be switching > from working-around-cpu-bound hypothesis to work-around-io-bound. Do > you know if anyone really uses jabberd2 in a distributed manner? The greatest bottleneck is single-threaded SM component talking do storage backend. As a whole, jabberd2 is strictly I/O-bound. (like most systems on modern machines - CPU got waaaay above the rest of the hardware) It's actually hard to distribute load in jabberd2. Router - there can be only one. SM - there can be only one per domain. The only useful distribution today is distribution of sockets talking to clients and other servers. On a fairly big deployment one can easily saturate the TCP ports per machine limit. Mark was working on SM distribution. His work is available at clustering SVN branch: http://svn.xiaoka.com/jabberd2/branches/clustering/ > I just wanted to point out that this went against the history of > jabberd2. It's not a technical issue :) Jabberd2 suffers many aspects of second system syndrome. I'm not really for big architectural changes. But as we were talking about this today, I realized that this would be fairly minor change. All components share the same codebase and main application skeleton, and could be easily (I think) joined to remove duplication. On a modern system (like linux 2.6) there will be not much change performance wise, I think. TCP sockets on 'lo' device are very fast. > Otherwise, I think it is indeed worthwhile direction. In fact, it > would be a big enough evolution to warrant renaming the project, as > you previously wanted, no? :) Well... I count on Matthias renaming jabberd14 to xmppd at last, so I could keep jabberd without confusion. ;-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
