Socket.io: Scaling socket.io on multiple servers and processes

[refaelos]

Hey all,

I'm using socket.io on multiple servers (several Azure machines) and processes (using cluster).
I found the regular answers that say I should use sticky sessions to make sure connections to an instance of socket.io will continue going to the same process between calls but I don't understand why sticky sessions are a good solution and how to solve this problem:

1. The was to implement sticky sessions is to have one "server" that is used as a kind of a proxy. This slows down the server and can create a load issue on some of the processes. It might take out the edge of having multiple processes.
2. How does sticky sessions solve the issue of having multiple different machines?
3. On earlier versions of socket.io I could set up a redis store that took care of that. Where did it go (and why?)?

Am I right in all my points here or am I completely off track?
Not sure what i'm missing.

Thanks in advance :)
We LOVE socket.io :heart:

[nkzawa]

If there's no sticky sessions, each server processes have to share session data of all clients among all processes, because you can't predict which client would connect to which server. You know that can cause a scalability problem and make the things complex. So a socket.io 1.x server handles sessions of only clients connected to it, and doesn't take care of others.

On earlier versions of socket.io I could set up a redis store that took care of that. Where did it go (and why?)?

You can use Redis Rdapter instead of Redis Store for Socket.IO 1.x. Adapter is designed not to share data among server processes as described above, and just publishes events to other processes.

For more information, please refer to the following:

http://socket.io/docs/using-multiple-nodes/
http://socket.io/blog/introducing-socket-io-1-0/#scalability

[refaelos]

I was using this redis adapter and still got the same issues as I had before. Are you saying that if I use the redis store I don't need the nginx or cluster sticky session solutions?

[nkzawa]

You can't use RedisStore for socket.io 1.x. RedisAdapter is the alternative.
What kind of issue did you get?

[refaelos]

There's something with the handshake never being completed when different calls go to different processes/machines when socket.io runs.

This is the error: failed: Connection closed before receiving a handshake response

Sorry to ask this again: "Are you saying that if I use the redis store I don't need the nginx or cluster sticky session solutions?"

[nkzawa]

Ah, that's the reason you have to use sticky sessions. A client always has to connect to a same server process.

[refaelos]

Ok... so you're saying I need the sticky session even if I use the redis Adapter?
The thing is that when I had the redis session store I didn't see this error.

[nkzawa]

Yes. RedisAdapter is only for publishing messages to other processes. You need sticky session too.

[refaelos]

bummer...

Is it a really bad idea to use the older version of socket.io (so I can use the redis store) ?

sticky sessions are a big problem when going to scale. It kind of takes out the whole purpose of having multiple machine/processes b/c on the worst case only some processes takes care of most of the load.

[tomcartwrightuk]

Using redis store for sessions might cause you to experience worse scaling issues than sticky sessions. If you are not fussed about using all transport mechanisms and want to remove the need for sticky sessions you could follow advice from here, https://github.com/Automattic/socket.io/issues/1598 and pass { transports: ['websocket'] } and enforce SSL. Sticky sessions are only needed for non-websocket transports.

[refaelos]

@tomcartwrightuk thanks! We'll try that.

[hussion]

@nkzawa can you provide a complete demo of socket.io with cluster ? i really need it, thanks very much ! because this #1944

[objectiveSee]

FWIW @Hussion We moved away from using Cluster because you would need RedisAdapeter for multi-instance scaling anyways. Instead, on each instance we create 34 Node processes listening on incrementing ports, then use HAProxy to balance between them.