On 6/5/08, Jean de Largentaye <[EMAIL PROTECTED]> wrote: > 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.
This point was addressed in other parts of the threads, so I'll skip it. > Wasn't it one of > the reasons of the redesign from jabberd14? > > 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? I can't speak for other implementations, but we're using a three node cluster with two front end nodes (c2s/s2s) behind a load balancer and one back end node (router/resolver/sm). I based this layout on a post from the jadmin list from a little while ago (<http://mailman.jabber.org/pipermail/jadmin/2006-September/098513.html>), with the major difference being that our mysql DB is in a cluster of its own separate from the jabberd2 cluster. I don't know that this is an ideal distribution (in particular, I'm questioning the placement of the resolver component -- not that this will matter when we upgrade to 2.2+), but it's worked well for us so far. > I just wanted to point out that this went against the history of > jabberd2. It's not a technical issue :) > > 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? :) > > Regards, > > jean > > > On 6/5/08, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > > We were talking with Ono today about merging all jabberd 2 sub > > applications (router, c2s, s2s, sm) into one binary, with multiple > > threads running each components. > > That would mainly reduce maintenance and deployment effort. You would > > run one process instead of several ones. > > And wouldn't keep one from running each component in separate process - > > just run only one thread+component in each instance. > > > > With such design there are some performance optimisations possible in > > router, that could just pass pointers to data instead of pushing the > > data through TCP sockets. > > There are some problems with current single-thread design of jabberd, > > but we think they are easily solvable. Ex. static buffers with thread > > local-storage. > > > > What do you think about this idea? > > Is it worth pursuing? Or not worth the effort? > > > > > > -- > > /\_./o__ Tomasz Sterna > > (/^/(_^^' http://www.xiaoka.com/ > > ._.(_.)_ im:[EMAIL PROTECTED] -Derek. The list's mail servers are rejecting mail from the entire psu(dot)edu domain. Until this is resolved, I will be using this temporary address, which I do not check. If you want to copy me off-list, use my primary address: <det135(a)psu(dot)edu>. N�����r��zǧu���[h���z�v��칻 �&ޖ+-���F��
