3 ms·
If you have 140M active users, handling a fleet of 1000 servers is not an easy operation, considering you need to manage inter-cluster communications (i.e. when
by nivertech 15y ago
If you have 140M active users, handling a fleet of 1000 servers is not an easy operation, considering you need to manage inter-cluster communications (i.e. when sender and receiver sockets fell on different servers).
I've built Erlang/OTP websockets clustered server, which can handle 3M per node (giving you have enough RAM). Here you handle all your users with "only" 47 servers.
There is a big operational and scaling difference between cluster of 1000 servers and cluster of 47 servers.
- jat850 15y agoI'm a bit curious about this. If you have 140M concurrent users (since this was the original complaint) and you are NOT prepared or capable of servicing/monitoring/maintaining 1000 servers, that seems like a fatal flaw in your server management and analytics processes. Certainly 47 servers vs. 1000 is far nicer. But at 140M concurrent users levels (there must only be a few handfuls of sites with these types of concerns), not having a team prepared to oversee 1000 servers seems like folly.
- nivertech 15y agoThe problem is not only operational, but also a technical one: Nodes in the cluster need to communicate with each other and with other systems, like databases, message queues, monitoring servers, etc. You can aggregate data per node, so the less servers in the front-end cluster you have, the less load on the back-end servers. There is also financial problem: many organizations can afford 50 servers. But not many can afford 1000 servers.
- axiak 15y agoThere's no reason why you can't have many node processes per server. This also raises the fault tolerance per server.