[jdev] Presence packets bottleneck on huge rosters

[Bresler, Jonathan]

One practical consequence for the XML stream is a separate <presence>
Stanza is sent from the server to the client for each contact.  I have
To check the karma code to see if the client connection's karma is charged
For this traffic.  

500 contacts means 500 <presence> stanzas, each one being something like 
150 bytes longs (payload, not including Ethernet, TCP and IP headers, 
call it 200 bytes in round numbers).  So we get 5 contacts per 1kB on the 
Wire or 100kB, which is 800kb on the wire.  Rather heavy duty. ;(  But there
Does not appear to be any choice at this time....so dribbling the presence
Data out to the client over some time period appears to be desireable.

I have to read the karma code understand the impact of traffic to a destination
On the karma (possible DOS against a user here?) and compare the release code of jabberd-1.4.3 to the cvs code to understand jabberd-14's handling of this better.

Jonathan



-----Original Message-----
From: Mickael Remond [mailto:mickael.remond at erlang-fr.org] 
Sent: Thursday, December 09, 2004 5:05 AM
To: Jabber software development list
Cc: Bresler, Jonathan
Subject: Re: [jdev] Presence packets bottleneck on huge rosters


Bresler, Jonathan wrote:
> Hello,
> 
> Large roster lists on active servers with a number of users are a problem.
> All the more so if the connections are encrypted.  The current jabberd14 code
> (reading, still have jabberd2 and ejabberd to read) sends out <presence> 
> Stanzas immediately.  This can be intense.
> 
> One easy to implement option, that might not twist the RFCs to hard, is to schedule
> The <presence> stanzas over some short time period using the heartbeats that are
> Available in jabberd14 (and presumeably jabberd2 and ejabberd).  

That was one of my thought. I did not know the heartbeat mechanism of 
Jabberd1.4. What are the practical consequences on the XML stream ? I 
mean for example, if you have 500 contacts in your roster, how would the 
server send the presence packets to the destination and how much time 
will it take ?

Another of my thought was to use some kind of message delivery 
scheduler, that would rearrange priority between messages. For example, 
normal messages would be delivered with a higher priority than presence 
packet. The scheduler could also play the role of the heartbeat to 
regulate the number of presence packet sent over an interval of time. I 
did not yet thought of all the implication of this change.

-- 
Mickaël Rémond
  http://www.erlang-projects.org/

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.804 / Virus Database: 546 - Release Date: 11/30/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.804 / Virus Database: 546 - Release Date: 11/30/2004