Live data from Hacker News

600k concurrent websocket connections on AWS using Node.js (2015)

blog.jayway.com

31–40 of 141 posts

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#31

I 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.

This is actually not true, if you take a really optimzied C/C++ library for WS Nodejs will crush Elixir by a large margin. Elixir / Erlang is slow and consume a lot of memories compared to more native languages or C libraries.

Ex: https://github.com/uNetworking/uWebSockets

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#32
post #17
post #15

A 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…

Could you explain or post a link to something about #2? I’ve never heard of that before!

I would also be interested in this. First time I hear about such a limitation.

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#33
post #4

So 1/4 of what Elixir/Erlang can handle, but more difficult and less reliable: https://phoenixframework.org/blog/the-road-to-2-million-webs...

Gary was using a much more powerful instance (both in cpu and memory) that this post uses when he reached 2 million with Phoenix. But Phoenix is also doing quite a lot more per connection than node. Basically for multiple reasons they're incomparable experiments, there's really no basis here to draw conclusions like '1/4 of what Elixir/Erlang can handle' from.

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#35

There is more performant web-socket implementation than the one mentioned in the blog. It can handle 6X more connections and much less memory https://github.com/uNetworking/uWebSockets.js EDIT: Note that the blog post is from 2015. There are many optimization (Ignition and TurboFan pipeline) has been done in V8 since then, especially offloading GC activity to separate thread than NodeJS Main thread.

Unfortunately it is written by someone whose technical ability far exceeds his people skills, which are essential for a library module that developers can safely depend on.

This is doubly unfortunate because I very much share his views on bloated frameworks etc. :(

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#36
post #15

A 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…

If you have a lot of trafic you shoudn't use an ELB in the first place, should be using an NLB by default it comes with a 40Gb pipe and multi millions connections.

https://docs.aws.amazon.com/elasticloadbalancing/latest/netw...

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#37

I 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.

There are a handful of languages that would be suitable for this. The "right one" to use depends on more than just the language features for that task:

- What third party libraries do you need to use? Some languages have very good support for some, and less for others.

- What are the internal integrations you need to support? Can they be over the network or are you calling into code in a particular language?

- What is the pool of skills available to you as a team? Do you go with a language that has a reputation of being really good for this task but of which the team knows very little (and therefore will have a learning curve working out the common pitfalls), or do you go with a better understood language which the team has already mastered, and stretch it to go beyond what mere mortals do with it? Note: there's no right answer here, both options have severe drawbacks.

- Related to the previous: what's your company's culture regarding technical diversity?

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#38
I thought this was going to be about AWS-managed websockets using API Gateway. I've been using that at a really small scale and it's got a great API but other than almost certainly being much more expensive than the EC2 machine used here I wonder how well it works with that sort of scale.

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#39
Does anyone have experience doing the same on GCP?

In particular right now I am trying to add live reloading to my App Engine Standard app but Standard doesn't support long lived connections (so no websockets) and App Engine Flexible seems like it will be pricy.

I think I can set up a single separate websocket instance which is only responsible for doing listen/notify on postgres and telling the client when it's time to refetch from the main webserver again.

Does this sound approximately workable? Will I actually be able to reach the connection numbers like in this article?

Re: 600k concurrent websocket connections on AWS using Node.js (2015)

#40
post #37

I 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.

There are a handful of languages that would be suitable for this. The "right one" to use depends on more than just the language features for that task: - What third party libraries do you need to use? Some languages have very good support for some, and less for others. - What are the internal integrations you need to support? Can they be over the network or are you calling into code in a particular language? - What i…

This is a very typical diplomatic answer to stick with old, known programming languages.
Post reply on HN