Have you results? Am Freitag, 3. August 2012 19:50:38 UTC+2 schrieb Jai: > > 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/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/bee1f4e7-cf79-4b94-a0c2-1679338ff820%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
