Hacker News Reader

Comment by evantahler | Hacker News Reader

Congrats on the release! I know this was a long time coming.

A scalability question:

You note "Turn on sticky load balancing (for example by origin IP address). This ensures that long-polling connections for example always route requests to the same node where buffers of messages could be stored."

I read this to mean that we are responsible (in our load balancer/proxy/etc) to keep connections from clients returning to the same server. This is OK, but what about nodeJS clusters? How should I ensure that client A always connects to cluster-node member 3?

Related section of the blog post: http://socket.io/blog/introducing-socket-io-1-0/#scalability

View on HN

The node.js cluster module is not flexible enough to be used with engine.io / socket.io / sockjs etc. Just run several processes and put something like HAproxy in front of them. If using a cookie to ensure stickiness, you can scale to multiple load-balancers easily.

That seems like a pretty big requirement that could frequently be deal-breaking. I would expect a big warning somewhere that you can't cluster if you're using socket.io.

I concur; we use sticky-sessions in our load-balancer, and stunnel when we're doing it on an SSL'd page, and it's working just fine.

As a note, I switched to Faye for most of my websocket needs because of this http://faye.jcoglan.com/

I tried using faye and it died very quickly under load with the redis backend. For every message that you send it queues it up into a redis list for each faye server in the cluster to read which doesn't scale very well in their very chatty redis queue system.

I would do significant load testing for each use case before using it (or socket.io for that matter). I needed to push 30-50 messages per second to each connected client and faye started choking as soon as there were more than 20-30 clients. socket.io would choke at around 50-100 connected clients. Raw websockets were able to reach closer to 100 clients but performed more or less similar to socket.io.

That's an incredibly high rate of messages. What could you possibly need that many messages for? I'm in no way surprised that generic solutions don't work for your case.

This: https://map.couple.me

We kept the design simple, otherwise a "batching" mechanism could be introduced that would replay a single batch of 50 messages but that would make everything a second delayed. However, part of the map allows you to login and see your messages live on the screen as you're sending them to your partner and for that the real time streaming is pretty critical.

I love Couple, I was looking at this map earlier this week actually. Very interesting to read how you made it work, thanks for sharing.

It looks like you're sending the same data to every client, but it sounds like Socket.IO/Faye aren't handling this well. Do they not have a `broadcast` method of something of that nature that handles your use-case?

Reply on news.ycombinator.com