Not really, because there won't be logs for connections that were never established.
How are you keeping track of those?
As I recall, when we hit the ELBs connection limits the failed connections were reflected in the SpilloverCount metric.
I believe we only hit the security group limits in load testing. There, we could see connections fail to an instance when that instance's established connections as reported by netstat or similar tools hit a certain threshold.
Ok, here's a better comparison: "Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby" https://hashrocket.com/blog/posts/websocket-shootout
> NodeJS performance is hampered by its single-threaded architecture, but given that fact it performs very well. The NodeJS server was the smallest overall in lines of code and extremely quick and easy to write. Javascript is the lingua franca for web development, so NodeJS is probably the easiest platform for which to hire or train developers. Do you actually read the blog post before making the claim ? The author i…
I expected all benchmarks that use the (linux) kernel for I/O events would perform similarly. The code is so small that the interpreter overhead should not degrade the performance too much. May be the JSON parsing / serialization?
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...
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.
This is a very typical diplomatic answer to stick with old, known programming languages.
Often case that isn't the wrong way to go. Newer doesn't mean better, and there's always trade-offs to consider. "It's newer" by itself really shouldn't be much of a consideration.
Erlang is older, more suitable, more stable and less well known. Nobody mentioned that it is better because newer.
This is a very typical diplomatic answer to stick with old, known programming languages.
Often case that isn't the wrong way to go. Newer doesn't mean better, and there's always trade-offs to consider. "It's newer" by itself really shouldn't be much of a consideration.
But in this concrete case his point is valid, I'd likewise expect Erlang's BEAM to outperform node.js in concurrency any day of the week. Elixir being new is fairly irrelevant because it compiles down to the same erlang BYTE CODE. Erlang is 30 years old.
Yeah, we used nginx-push-stream-module[1] to support 1M connections with lower boxes. Websocket-as-a-service. Really cool module. Was a realtime project for a live TV contest where people could participate with their phones. [1] https://github.com/wandenberg/nginx-push-stream-module
Did not know about this module. Instead, we are using a pretty identical one [1]. Works flawlessly [1] https://github.com/slact/nchan
Often case that isn't the wrong way to go. Newer doesn't mean better, and there's always trade-offs to consider. "It's newer" by itself really shouldn't be much of a consideration.
Erlang is older, more suitable, more stable and less well known. Nobody mentioned that it is better because newer.
No, but the person I'm responding to is implying that using old, known languages is somehow a bad thing.