101–110 of 141 posts
I wonder how it would compare in terms of cost with doing it via the api-gateway. It would depend on how your app and user base scales and what the sockets are being used for I suppose. https://docs.aws.amazon.com/apigateway/latest/developerguide...
Earlier quoted context omitted.
> 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 restart or replace an instance, etc. I came here to say this. Horizontal compute is a miracle.
How meaningful is the benchmark for handling idle connections? Handling more is better, of course, but if the server melts down when 0.1% of them have any activity, maybe maximizing idle connections isn't the right place to expend optimization effort?
Doesn't sound so impressive. I've done close to a million on a single Digital Ocean droplet using nchan[0] before. Latency was reasonable even with that many connections, you just need to set your buffer sizes carefully. Handshakes are also expensive, so it's useful to to be able to control the client and build in some smart reconnect/back-off logic. [0] https://www.nginx.com/resources/wiki/modules/Nchan/
Genuinely missing the point question: isn't the number of concurrent socket (websocket or otherwise) connections just a function of the underlying OS and number of instances thereof, not a function of Node.js ?
Earlier quoted context omitted.
Could you explain or post a link to something about #2? I’ve never heard of that before!
I can not. AWS, for whatever reason, does not want this publicly documented. I would write up what we learned in our testing in more detail, but I have been asked not to. You can find some discussion of this behavior in places like https://forums.aws.amazon.com/thread.jspa?threadID=231806 . I originally became aware of the issue, before hitting in production, from the HN comment at https://news.ycombinator.com/item?i…
I myself found out about to avoid the connection tracking in this thread https://news.ycombinator.com/item?id=15724072
It's super frustrating that Amazon doesn't document this in a more approachable manner.
Earlier quoted context omitted.
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...
We did not use an NLB because it is expensive in its pricing model for TLS connections (and we prefer to let AWS terminate TLS). For 20 million connections, an NLB would cost $28,800/month. It's drastically cheaper to use an ELB, provided you can talk to AWS to have them scale it for you.
Earlier quoted context omitted.
You can also employ DNS round robin with health checks in Route53
DNS round robin has the disadvantage of not guaranteeing that the traffic will be equally distributed. This can be a problem if there's a lot of automated traffic. But, with that said, in term of price, it's unbeatable.
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...
Sorry to be that guy, but I can find a TON more people capable of supporting ECMA vs. Erlang and/or Elixr. I say this as a huge fanboy of both.
I know I'll get rolled on HN for saying this because we all drink the optimization Koolaid but I feel this is worth mentioning.
Genuinely missing the point question: isn't the number of concurrent socket (websocket or otherwise) connections just a function of the underlying OS and number of instances thereof, not a function of Node.js ?
it wasn't long ago that even managing 10K connections on a server was considered quite a feat - see http://www.kegel.com/c10k.html