Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Socket.io 1.0

socket.io

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Introducing Socket.io 1.0

#51

Post by mpetrov »

thedufer wrote: post #24
woah wrote: post #5

Have you guys dealt with the 3-year clustering bug? https://github.com/Automattic/socket.io/issues/438 Would be pretty hesitant to use it until there's some sort of closure on this.

It 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.

Sticky load balancing was a deal breaker for us when we built the 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.

Re: Introducing Socket.io 1.0

#52

Post by mpetrov »

evantahler wrote: post #32
evantahler wrote: post #16

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 t…

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.

Re: Introducing Socket.io 1.0

#53

Post by antonapa »

xhrpost wrote: post #23

I've used Socket.IO quite a bit, congrats on shipping! Did the issue/"lack of feature" get fixed where not all transport methods fire a disconnect event? That was especially a pain on a recent project, ended up forcing websocket only to get around it. EDIT: Ack, I should probably clarify this better. The issue is that a client disconnected is not determined by the server. The server waits for the client to send a dis…

I solved this by firing an event on window.beforeunload. Had the same issue.

Re: Introducing Socket.io 1.0

#54

Post by thedufer »

mpetrov wrote: post #52
evantahler wrote: post #32

Earlier quoted context omitted.

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 connect…

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.

Re: Introducing Socket.io 1.0

#55

Post by EGreg »

lpinca wrote: post #50
EGreg wrote: post #41

Earlier quoted context omitted.

someone should do primus vs socket.io why would I need engine.io,websockets for example when engine.io already uses websockets if it can upgrade the connection to them?

You can't use both. In Primus you can select only one transformer, listed above by V1, but if something doesn't work, you can just switch it with a single line of code. No rewrites, no need to learn a new API.

I know you can't use both, but doesn't engine.io already support websockets?

Re: Introducing Socket.io 1.0

#56

Post by weixiyen »

Oculus wrote: post #46

The undoubtable mention of SockJS will appear multiple times in this thread. Socket.io has been plagued with scalability issues since its original release (can't speak on the new version) and Engine.io is suppose to be fix that. The main difference between SockJS & Socket.io is their connection establishment. SockJS begins by attempting to use Websockets and regress to long polling while Engine.io starts with long po…

> Socket.io has been plagued with scalability issues since its original release

How does that affect scalability, or how is that related to your comment?

Re: Introducing Socket.io 1.0

#58

Post by thedufer »

Rauchg wrote: post #6
woah wrote: post #5

Have you guys dealt with the 3-year clustering bug? https://github.com/Automattic/socket.io/issues/438 Would be pretty hesitant to use it until there's some sort of closure on this.

Please read the "Scalability" section on the blog post! This very demo is fully clustered.

Its 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.

Re: Introducing Socket.io 1.0

#59

Post by rafaelc »

8ig8 wrote: post #57

It sounds like Automattic deserves some thanks for their support on this. Thank you.

They do. Worth noting that A8C acquired our company LearnBoost/Cloudup in 2013, where we had built/supported Socket.IO and many other Node.js libraries for the prior +3 years

Re: Introducing Socket.io 1.0

#60

Post by Vekz »

Oculus wrote: post #46

The undoubtable mention of SockJS will appear multiple times in this thread. Socket.io has been plagued with scalability issues since its original release (can't speak on the new version) and Engine.io is suppose to be fix that. The main difference between SockJS & Socket.io is their connection establishment. SockJS begins by attempting to use Websockets and regress to long polling while Engine.io starts with long po…

I second @weixiyen. You bring up "Socket.io has been plagued with scalability" and then elaborate on the irrevalant graceful degradation strategies of each framework
Post reply on HN