Cluster?

[hunterloftis]

Cluster?

[majek]

sockjs-node has some internal state - mapping from sockjs session number to an internal structure (consisting of, above all others outgoing message buffer). As node cluster is basically equivalent to fork, it doesn't share this state across forks and will not work with sockjs-node. Additionally, I can't see how this state could be shared and there doesn't seem to be any option for doing a custom routing (ie: forward all requests from session A to worker B).

As a side note node clustering should work with sockjs if only websocket transports were used (as there is not much internal state stored for that).

I'm afraid you have to run multiple workers on different ports and do balancing using for example haproxy (with sticky sessions). We have a sample haproxy config prepared.

We could make sockjs-node working with node clustering, but it's probably going to be quite hacky, and an overkill for now. Is it a big deal?

[hunterloftis]

It's something I may contribute to sockjs - we have solved the problem before with socket.io by using redis as a pubsub server.

We could basically copy Express's Session concept - it uses a MemoryStore instance by default but can optionally (and always in production) be set to a RedisStore. Thus, when creating a new SockJS instance you could optionally pass it a RedisStore (or other store) to replace its default MemoryStore.

For real deployment we've found that Cluster is necessary (otherwise you're using only 1 of 4 or 8 possible cores).

By the way please let me thank you for writing SockJS. It's a nice solution and I hope to use more of it.

[majek]

Interesting! I would prefer to keep sockjs-node as thin as possible (think: don't require redis), I hope this is possible.

MemoryState? Link please :) Also, are there any other ways of sharing the state between cluster threads?

SockJS has few big users which do use multiple cores - the solution is to spawn multiple node.js processes, each using different http port and combine that using a loadbalancer. That seems to be working fine for many people. (Although, cluster may be simpler to deploy)

[majek]

I won't do implement clustering any time soon. Patches welcome :) (but beware, that can be hard or maybe even impossible due to the in-memory state every connection has, which would need to be shared between threads)

[paulbjensen]

Hi,

I stumbled across this library when researching Socket.IO and Node's cluster API:

https://github.com/fent/clusterhub

It might be of interest with regards to finding ways to share the state between cluster threads without relying on an external dependency like Redis.

[majek]

@paulbjensen clusterhub looks interesting. Unfortunately, it is not really suitable for SockJS.

SockJS already supports "scaling" - just deploy multiple servers and put a sticky-sessions aware load balancer in front.

We could add support for node-style clustering, but this will only complicate manner - users would have two ways of scaling: a) on local machine using node clustering b) on local machine OR on multiple machines using loadbalancer.

Although a) is more idiomatic, I think that any user seriously wanting to scale would prefer b), as it can grow outside a single box, while a) can't.

[paulbjensen]

@majek. Cool.

I'm currently doing what you've recommended, but instead of using HAProxy, I'm using node-http-proxy with a custom npm I've developed to do both round-robin and sticky-sessions, which proxies requests to an app server running 4 instances (1 per CPU) of a SocketStream app with SockJS.

[majek]

I've not yet been able to get websockets running through node-http-proxy, but I haven't tried too hard. Give me a shout if you succeed.

[konklone]

node-http-proxy does support proxying Websockets, and I've verified it working on my own machine:

https://github.com/nodejitsu/node-http-proxy#proxying-websockets

[majek]

Good to know. Thanks