3 ms·
Have you guys dealt with the 3-year clustering bug? https://github.com/Automattic/socket.io/issues/438 https://github.com/Automattic/socket.io/issues/438 Would
by woah 12y ago
Have you guys dealt with the 3-year clustering bug? https://github.com/Automattic/socket.io/issues/438 https://github.com/Automattic/socket.io/issues/438
Would be pretty hesitant to use it until there's some sort of closure on this.
- Rauchg 12y agoPlease read the "Scalability" section on the blog post! This very demo is fully clustered.
- thedufer 12y agoIts dependent on sticky load balancing - a pretty big caveat. And as far as I can tell, it still doesn't work with the cluster module, which is what that issue is about.
- thedufer 12y agoIt appears that the answer is "kind of". You can't use cluster, but you can put multiple processes behind a load balancer if the load balancer can do sticky routing. They should probably be a lot more explicit about this; the scalability section seems to avoid mentioning that socket.io isn't compatible with the cluster module.
- mpetrov 12y agoSticky load balancing was a deal breaker for us when we built the https://map.couple.me https://map.couple.me visualization with socket.io. At the last minute I just pulled older browser support and left it with raw websockets instead of socket.io because the cluser module couldn't be used otherwise. We had two issues with sticky load balancing: 1. AWS ELB had to run in TCP mode (for websockets) which meant no stickiness 2. Within each instance we have a node-cluster running to utilize multiple CPUs and putting haproxy with stickiness there increased complexity We could avoid using the ELB but then you lose the ability to use an EC2 Auto Scaling group, introducing significant admin overhead. Ultimately we didn't need the nodes communicating between each other (it's a one way stream from us to the client) so raw websockets ended up being the simplest solution.