600k concurrent websocket connections on AWS using Node.js (2015)
11–20 of 141 posts
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#12Why is this specific to AWS ?
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#13Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#14Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#151) Consider not running the largest instance you need to handle your workload, but instead distributing it across smaller instances. This allows for progressive rollout to test new versions, reduces the thundering herd when you restart or replace an instance, etc.
2) Don't set up security group rules that limit what addresses can connect to your websocket port. As soon as you do that connection tracking kicks in and you'll hit undocumented hard limits on the number of established connections to an instance. These limits vary based on the instance size and can easily become your bottleneck.
3) Beware of ELBs. Under the hood an ELB is made of multiple load balancers and is supposed to scale out when those load balancers hit capacity. A single load balancer can only handle a certain number of concurrent connections. In my experience ELBs don't automatically scale our when that limit is reached. You need AWS support to manually do that for you. At a certain traffic level, expect support to tell you to create multiple ELBs and distribute traffic across them yourself. ALBs or NLBs may handle this better; I'm not sure. If possible design your system to distribute connections itself instead of requiring a load balancer.
2 and 3 are frustrating because they happen at a layer of EC2 that you have little visibility into. The best way to avoid problems is to test everything at the expected real user load. In our case, when we were planning a change that would dramatically increase the number of clients connecting and doing real work, we first used our experimentation system to have a set of clients establish a dummy connection, then gradually ramped up that number of clients in the experiment as we worked through issues.
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#16Earlier quoted context omitted.
One possible use is for high traffic websites. For example, StackExchange peaked at 500k concurrent websocket connections back in 2016. [0] [0] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
Surely not on one endpoint
One of the arguments I make when people say microservices + cloud built to the core is the only way to scale - clearly a cleverly architected approach can save you lots on hardware/hosting money.
[0]: https://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-... [1]: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#17A few pieces of advice based on running https://github.com/mozilla-services/autopush-rs , which handles tens of millions of concurrent connections across a fleet of small EC2 instances. 1) Consider not running the largest instance you need to handle your workload, but instead distributing it across smaller instances. This allows for progressive rollout to test new versions, reduces the thundering herd when you restar…
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#18A few pieces of advice based on running https://github.com/mozilla-services/autopush-rs , which handles tens of millions of concurrent connections across a fleet of small EC2 instances. 1) Consider not running the largest instance you need to handle your workload, but instead distributing it across smaller instances. This allows for progressive rollout to test new versions, reduces the thundering herd when you restar…
Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#19Re: 600k concurrent websocket connections on AWS using Node.js (2015)
#20I don't get point of using Node.js when compared to something like Elixir. Elixir's Phoenix can handle more numbers of concurrent connections as well as provide reliability with better programming abstractions, distribution, pretty good language.