Presence and IntComm WG

[Jorj Bauer <>]

> Some notes from the Prosody perspective...
>
> From the screencasts you made I note that Prosody stabilised at 16ms
> latency, and ejabberd at 17ms latency, 1ms can make all the difference
> ;-)

Hi Matt! Thanks for pointing out my mistake. Technically, Prosody is  
the fastest, ejabberd second, and OpenFire third. I suspect the fine  
line between Prosody and ejabberd can be tuned a billion ways to make  
either one faster than the other under some specific conditions.

> I recall that the main issues you had with Prosody were that modifying
> the contact list is not fast (on the plus side, reading is very fast,
> which is the most common case). However if you really do need
> thousands of contact list modifications each second then I guess the
> upcoming support for different data backends will help a lot.

This isn't a major concern for me, although it seemed  
uncharacteristically out of line. As you say, it's an infrequent  
occurrence. I'm more interested in making sure that it has the  
appropriate usability characteristics (see below).

> The second issue was with connect/disconnect taking some time with
> lots of clients. I'm really hoping this will be much better with the
> new connection framework landing in 0.7, so would be glad if I could
> poke you to re-run your tests then.

This one I am interested in. This performance problem could be an  
issue. Although it's not the major one (read on).

> I'm curious when you say that all three servers crashed under load...
> exactly in what manner did Prosody "crash"? or do you simply refer to
> the slowness in dealing with connections?

This is the one that I'm most concerned about - in all three services,  
actually.

At about 1300 simultaneous connections, Prosody crashed. Hard. Would  
core dump, if I let it. This is clearly a problem with libsocket, and  
I expect that you'll overcome it when you move off of that  
underpinning. I look forward to testing this again with 0.7.

For ejabberd, the ejabberd process exited when I hit about 5000  
simultaneous connections (although this limit can be changed by re- 
tuning the process).

With OpenFire, the process hung (would not pass packets, would not  
accept new connections - which remained in a half-open state) at about  
3k connections. Again, this is tunable by changing Java heap. But the  
fact that it fails in this particular way is very bad; the server  
can't detect that something is wrong without parsing logs or  
attempting protocol-level connections. With both Prosody and ejabberd,  
it's easy to tell that the process has terminated and something is  
wrong.

For all three, I would have preferred to see a setting in the server  
that sets the maximum number of open connections, at which point the  
server stops accepting more (and presumably emits lots of warnings).  
This would allow the service to continue to function normally for  
everyone that's still connected, while avoiding a DoS condition.

> Overall your research was *very* helpful to us, so I'd like to say  
> thanks!

I'm glad, and hope that it benefits others as well (once I've finished  
it up and release it in the wild). Thanks for working with me on this  
- I found the attitude of the Prosody developers very pleasant and  
refreshing. Nice to see a project with functional goals and folks  
interested in constructive feedback!

-- Jorj

Attachment: PGP.sig
Description: This is a digitally signed message part