2009/6/13 Tomasz Sterna <[email protected]>
> The largest problem for large jabberd2 deployments is a single-process, > single-threaded Session Manager. > Being single-threaded means that it can process only one XMPP packet at > a time. More importantly, when it waits for some data (from the storage > mostly) it does not process any other packets. > > One possible solution would be to rewrite the SM to be multi-threaded. > And I do mean rewrite - the way it is designed now, would mean rewrite > (or reassembly) from scratch. > > Other possible solution is to make the SM multi-processed. This means a > possibility to launch many Session Manager instances to service one XMPP > domain. This would balance processing load between many processes > (possibly machines) and spread storage load on many separate DB > connections. > > Most server implementation approach this with a separate ‘clustering’ > component, which tracks which session component is handling which user. > In case of jabberd2 I think it is not necessary. We already have the all > decision making overseer - the router component. > > I just committed to SVN trunk a router version, that handles many SM > and/or external components (i.e. transports) instances for one XMPP > domain. Router select the destination instance using a hash of user JID > (receiver in case of SM instances, sender in case of external > components). This is an approach that most clustering HTTP deployments > use, which select the web server using session-id hash. > > This is not yet heavily tested and I count on you guys - please test it > with your installations and report any bugs spotted. > > > -- > Tomasz Sterna > Instant Messaging & EDI Consultant > Open Source Developer > http://tomasz.sterna.tv/ http://www.xiaoka.com/ > > > -- > To unsubscribe send a mail to > [email protected]<jabberd2%[email protected]> > >
