Hello, I am struggling with few approaches to run Node.js, before I go for benchmark which requires lot of work I wanted more experienced users to comment on following approaches.
Aim is to run a chat like project that needs to scale, requires fail-over and should have low latency. We will have multiple servers in different locations. Apart from above considerations we should also consider difficulty of coding in these approaches. Approach one 1) Multiple servers say X,Y,Z 2) Every server has multiple node.js (NJ) process say A,B,C 3) Stats server keeps no.of connections log of all NJ process on all servers. Hence it knows which NJ has high load. 4) Each NJ process keeps track of connected users (room information), this info is not shared. 5) All room users connect to single process of server X and single process of Y for e.g. they connect to A.of.X and C.of.Y Users can send packet to any of these two process and that packet will be broadcasted to everyone in room. Users connect with two process on different server for failover, users can send message to each process in round robin fashion. 6) Latency checks between all users and servers is made in background. All users in room are prompted to switch to preferred two servers. Stats server is also checked to see if preferred servers already has high load. It is important that all users in room connect to same pair of NJ process. ====== I am not sure if it would be possible to change websocket connection to a different servers as mentioned in (6) Approach two 1) Multiple servers say X,Y,Z 2) Every server has multiple node.js (NJ) process say A,B,C 3) Some kind of load balancer (HAProxy) is used to share load between all A,B,C processes between server. 4) Stats server keeps no.of connections log of all HAProxy. Hence it knows which HAProxy has high load. 4) Rooms info is stored in database (REDIS) which is shared between all NJ of server. 5) All room users connect to a pair of servers. Users can send packet to any of these servers and that packet will be broadcasted to everyone in room. Users connect with two servers for failover, users can send message to each server in round robin fashion. 6) Latency checks between all users and servers is made in background. All users in room are prompted to switch to preferred two servers. Stats server is also checked to see if preferred servers already has high load. It is important that all users in room connect to same pair of servers. ====== Maybe node.js cluster module can be used in place of HAProxy. Approach three 1) Multiple servers say X,Y,Z 2) Every server has multiple node.js (NJ) process say A,B,C 3) Some kind of load balancer (HAProxy) is used to share load between all A,B,C processes between ALL servers. 4) Stats server keeps no.of connections log of all HAProxy. Hence it knows which HAProxy has high load. 4) Rooms info is stored in database (REDIS) which is shared between all NJ of every server. 5) Users can connect to any server. 6) Using geographical LB (or DDNS approach) users are directed to server closer to them. Users in one room need not have to connect with same server. ====== All servers connect to central (redundant) REDIS server, this would increase response time as NJ has to wait for network connect time to get room list before broadcasting packets. Approach four Compared to Approach three, here instead of keeping a central REDIS we keep synced copies of REDIS on every server. This would eliminate network connect time but would increase memory footprint. What do you say? -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
