[Standards-JIG] Re: MUC traffic issues

Ulrich Staudinger us at activestocks.de
Sun Feb 19 19:46:22 UTC 2006


Philipp Hancke schrieb:

> Ulrich Staudinger wrote:
>
>> Anyway,
>> 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:
>> ------------------------------------
>> bridging MUC COMPONENT
>>
>>   /      |      \
>>
>>  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.
>
> Have you considered writing a MUC implementation which is capable of 
> doing
> S2S? Having a server act as a transparent proxy is highly undesirable
> in high-load scenarios.
>
I tested MUC directly attached to one server on the same machine and 
having two servers on other machines. To the other machines, the clients 
connect. The throughput stays the same, 2k incoming + 2k outgoing 
mess./minute on the connection servers.

I always need to consider distribution, because i need to host more than 
100k users ....

And that of course means that i will have approx. 200k outgoing messages 
per second inside the whole distribution. Yes, that is large, but it's 
the dimension i need to work in right now ...


-------------- 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/3ecc272c/attachment.vcf>


More information about the Standards mailing list