"diego.ca...@gmail.com, Sep 19, 2010
... In my case, I've been forced to suddenly stop my work ... with node.js because it cannot handle more than ~140K websockets concurrent connections ..."
"erik.corry, Nov 2, 2010
The limit for 64 bit V8 is around 1.9Gbytes now. Start V8 with the --max-old-space-size=1900 flag."
I'm doing something similar with node.js now to handle millions of concurrent connections. I use multiple node.js servers to handle it. Not only it helps in even out the load, it has the nice failover property. One node down doesn't mean the whole app is down. Clients of the down node migrate their connections to the rest of the nodes.
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.
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.
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.