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.

I’m running clustered jabberd2 on Chrome.pl with no problems.