[Standards-JIG] Re: MUC traffic issues

Ulrich Staudinger us at activestocks.de
Sun Feb 19 19:35:11 UTC 2006

Alexander Gnauck schrieb:

> Hal Rottenberg schrieb:
>> MUC Multicasting.
> yes, but not only muc. Pubsub and other protocols will have the same 
> problems once the are commonly used.

Basically the problem that i ran into was the sheer amount of messages.
In a bigger chat environment you have more, but while testing i used 
1000 users on one server.

When i have 1000 users, sendin 2 messages per minute each, packed in 
rooms with 50 users each, i have 2000 messages per minute * 50 
participients = 100000 messages per minute.
This means 2000 messages per second.

In case of external component:
* These 2k messages must come into the server
* 2k messages must go out of the server

Means 4k messages per second. This is not such a big problem with 
ejabberd and a fairly new machine, actually, i could scale on one 
machine up to 2000 users under these circumstances. Anyway, it won't 
distribute inside the cluster (session database is the keyword, and the 
queries to the session database to check on which server inside the 
cluster a user resides).

when we have some sort of a integrated pubsub into the servers, and an 
on this based MUC protocol, we would have something like this:

   /      |      \
  S1     S2      S3

with S1, S2 and S3 acting as replicators of the messages coming from muc.

This would instantaneously half the amount of messages per minute on S1 
and would also DRAMATICALLY take away load from the bridging MUC 
component, which does in current implementations need to replicate the 
messages itself. Of course this gained cpu time leaves power for 
additional MUC management stuff, like filtering, checking permissions, etc.

In my reference implementation i have used a plain PubSub node, to which 
users subscribe to (this is not good, because the component should be 
able to subscribe users to the PubSub node). Users do then send a plain 
message to the muc component, which does add additional informations to 
the message. Then the muc component does publish the groupchat message 
to the different servers' pubsub directories to the room node and the 
servers take away the load of replicating the message.

Feedback welcome.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: us.vcf
Type: text/x-vcard
Size: 329 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060219/40ef9e67/attachment.vcf>

More information about the Standards mailing list