7 ms·

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 h

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 12y ago
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 12y ago
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-web-stomp/ http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq...