Cluster support with sticky sessions #803
-
|
Hi, Does uWebSockets support sticky sessions when using NodeJs cluster module. Something like this https://github.com/indutny/sticky-session? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 3 replies
-
|
By sticky session I mean a mechanism to sticky different web socket connections (for example from different browser tabs) to the same worker process based on some header/cookie/ip address. There are such implementations for Socket.IO: https://github.com/indutny/sticky-session |
Beta Was this translation helpful? Give feedback.
-
|
Seems like a socket.io problem not applicable here |
Beta Was this translation helpful? Give feedback.
-
|
This is not a socket.io problem, on the contrary, there are ready implementations for socket.io (some explanation here https://github.com/elad/node-cluster-socket.io) and I am trying to figure out if it is possible to implement this load-balancing mechanism for uWebSockets.js We have a uWebSocket.js server, currently running without a cluster module. Our goal is to load additional CPU cores by using cluster module but make sure that all connections are routed by some key to the same worker process which contains some heavy state (opened database cursors) that should be reused between all requests with this key. The projects i'm referenced used an approach with a proxy logic that pause a raw socket and pass it to the certain worker node by custom balancing logic. So, I'm trying to figure out may be someone has already implemented this logic for uWebSockets.js. Currently I'm trying to implement this load balancing logic and stucked with App.listen() method that doesn't accept an already opened socket as param. |
Beta Was this translation helpful? Give feedback.
-
|
Your post that you spammed to 3 different places only mentions an issue specific to socket.io where socket.io can't work without a fix, you need to be more specific if you expect help, passing sockets to specific workers is already an open issue here #766 did you look at this issue at all or just post 10 different times without looking at the open issue? |
Beta Was this translation helpful? Give feedback.
-
|
As @uNetworkingAB mentioned you can also have a proxy decide which worker/port to send the request to, have each worker listen on different port, proxy looks at request and routes to port |
Beta Was this translation helpful? Give feedback.
-
|
@e3dio It's definitely not spam, at least not intentionally. When you are switching between two repositories with the similar names that differs only by two letters, it's quite easy to get confused. I've quickly noticed a mistake, but unfortunately there are no delete button. In any case, I apologize for the inconvenience. As for open issues, off course I've searched opened issues, but nothing relative was found for keywords in terms of the problem (clustering, sticky, load balancing). In terms of implementation I see now two discussions, thanks for the link. Implementation idea (of pausing and passing the socket to workers) was reached me lately. Thanks for highlighting the related issues, although they don't help me in anyway. Will investigate the sources code more. By proxying logic I meant a load balancing logic on the nodejs cluster level, not a proxying as an architectural approach with a proxy middleware. Proxying as an architectural approach with a middleware (nginx, haproxy) off course should work and it was the first idea, but it solves a different task - scaling at solution level, but I'm searching a way for a scaling at the node js server level. If you use different sockets (ports) for different tasks you do not need nodejs clustering. An approach with a middleware requires more server resources and has complexity in CI&CD deploy strategy and monitoring. |
Beta Was this translation helpful? Give feedback.
-
|
No worries I am just teasing you a bit. Currently you can't pass sockets to different workers in uws that is node.js only feature. If you are like me using proxy on same machine https://github.com/caddyserver/caddy it helps with things like #797 and it is very easy to route requests to different workers with minimal resource usage
The benefit is you can share memory with threads in the same process with worker threads, messaging and broadcasting between threads is easier etc, easy to listen on different ports |
Beta Was this translation helpful? Give feedback.
-
|
If you except expect a particular load balancing logic based on some key you need to implement that yourself using for instance a proxy or something similar |
Beta Was this translation helpful? Give feedback.
-
|
You can solve that problem using Redis. |
Beta Was this translation helpful? Give feedback.
If you except expect a particular load balancing logic based on some key you need to implement that yourself using for instance a proxy or something similar