[elierotenberg]

This benchmark is indeed very interesting.

I think I may have failed to express my point, though. I'm not building a message queue, as it is certainly a very hard problem that has been engineered for years by people way smarter than me :) I'm merely leveraging the goodness of their implementations (in my case redis, but RabbitMQ is also an option I've considered explicitly in my post).

The chat is a contrived example to show that even under high load, full-scale flux over the wire is a reasonable option. As for "any kind of serious load", well, maybe my example fails to meet the requirements, but unless I'm building Facebook, I think I've faced something serious enough to be able to think about my next step.

[jacquesm]

If you're building a large scale chat service you are implicitly also building a message queue.

And as for the high load you haven't actually experienced high load until you put this into production with a million users.

To make that clearer: you can design a system for any number of users, the only relevant question is how it held up in practice and as long as you haven't had a million concurrent users you just don't know (and probably it won't).

[moe]

I'm not building a message queue

That may be the kernel of the problem here; you built a subset of a message queue without realising it.

RabbitMQ has a websocket plugin[1]. Just make your javascript connect directly to a RabbitMQ cluster and you have a solid, scalable foundation - almost for free.

[1] http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq...