And again for the explanation about the process delay and the explanation about mnesia and its role in the auth process. Sometime in the near future I’ll be circling back on this and investigating what the cost would be under load for auth only, auth+presence, auth+presence+roster with the various built-in and one custom auth model for ejabberd.

I suspect that odbc based auth (which is what you want for semi-elastic scaling via clustering for a domain) will be even slower. But, as you pointed out, you get other benefits that may outweigh the overhead.

I forgot about ejabberd’s ‘process_delay’ feature. At every request ejabberd’s BOSH interface waits per default 100ms for incoming data from the server in order to reduce the overall number of requests. If one would test a real client login with loading roster and handling all incoming presence (which is a bit hard to determine automatically) I’m pretty sure the results would look quite different. But anyway. I did my tests again with process_delay set to 10ms and got a value of 417ms for ejabberd. Which is significantly lower then the first value but still significantly higher than all others.
I’ve also tried setting process_delay to a value lower than 10ms but then ejabberd doesn’t seem to work at all anymore. Probably there’s a bug. Anyway, as there are exactly 4 roundtrips involved with a single login the maximum time that could be safed by lowering process_delay would be another 40ms.

But I think a process_delay anywhere between 10ms and 100ms is a good thing for the overall client experience.

As to your question about NXB being slower than native implementations: An external component will always be slower than a native BOSH interface (if its logic itself is comparably fast) because it has some overhead involved. It needs to establish another tcp/ip connection between the CM and the server and it needs to parse the BOSH request and then the request must be parsed again at the server. While a native interface only needs to parse the whole request once.

In case of ejabberd the BOSH interface itself is so much slower than the external component that those advantages just don’t have much effect.

My guess is that ejabberd’s BOSH might be so slow because of the involvement of mnesia. Which also makes ejabberd’s BOSH interface quite different from the others as it is clusterable without any further requirements. So maybe the pure speed comparisons are not totally fair.

Also, any explanation/theories as to why NXB is slower proxy’ing tigase and prosody … but faster than ejabberd native?