Earlier quoted context omitted.
> Single-request connections. What does that mean? You keep qualifying "connections." It's a connection. It holds onto it's connection for X period of time. An HTTP request is just a single-request connection, which is NOT what this article is discussing.
One HTTP connection, one request, one response, connection closed. I admit I didn't first see that they actually don't do any i/o over those connections. Well, you know, handling x accepts() per second and holding onto y fds is even less than nothing to be proud of.
Achieving 100k connections per second with Elixir
61–70 of 117 posts
Re: Achieving 100k connections per second with Elixir
#62Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
I don't know Go, but that probably depends on your goals. To quote myself from elsewhere: > Efficiency in the BEAM is mainly in service of its primary goal of fault-tolerance. If one process crashes unexpectedly, the others should continue. By the same logic, if one process is CPU-intensive or IO-blocked, the others should keep making progress smoothly. And if processes are good for isolating errors and performance i…
Re: Achieving 100k connections per second with Elixir
#63Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
Both of them give you less flexibility than is necessary to achieve highly efficient use of all threads on a multiprocessor system. For that, you'll need something like a pool of event loops using async/await. This is the system most common in high performance networking in C++, C, and Rust.
Erlang and Go both sacrifice efficiency to improve maintainability and safety by offering a model that allows you to approach concurrency from a more synchronous mindset. Erlang in particular goes beyond Go in that the Actor model is considerably easier to avoid deadlocks and other concurrency bugs in at the expense of a much more opinionated system. Erlang is also less focused on reducing average latency as much as keeping latency predictable at scale.
Long story short, Erlang, Go, and the rest are not apples to apples comparisons, and it takes investment in each language to understand the tradeoffs and use cases for each. You should also view them holistically, as in, what language can my team support, and will the wins from Erlang's message queues outweigh the smaller community, or will Go's mid tier performance be enough to avoid writing on top of the low level libevent and building a custom thread pool or fine tuning Go's scheduler.
Re: Achieving 100k connections per second with Elixir
#64Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
In terms of raw performance, Go will be faster. However, the differentiator here is that the BEAM gives you the guarantees and tools to write highly concurrent applications with a sane mental model, fault-tolerance, and isolated processes. As a sibling said, it's fairly easy cluster applications. Additionally, if something truly needs to be ran in another language for performance, you can write a NIF in Rust or somet…
Re: Achieving 100k connections per second with Elixir
#65Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
As far as from my tests and what I've seen reported online, Go and Rust have a substantial lead (20% ish) over Erlang for high throughput servers. EDIT: I believe this is partially due to Go being a lot more CPU efficient overall than Erlang (see below). So for simple servers, Go and Erlang will match performance, but for slightly more complex web servers that need to crunch some data, Go [and Rust] will outperform t…
Re: Achieving 100k connections per second with Elixir
#66Re: Achieving 100k connections per second with Elixir
#67Earlier quoted context omitted.
We used Ubuntu 18.04 with the 4.15.0-1031-aws kernel, with sysctld overrides seen in our /etc/sysctl.d/10-dummy.conf. We used Erlang 21.2.6-1 on a 36-core c5.9xlarge instance. To run this test, we used Stressgrid with twenty c5.xlarge generators.
omg. 100K/sec was achieved by yours truly 10 years ago on a contemporary xeon with nothing but nginx and python2.6 - gevent patched to not copy the stack, just switch it. (EDIT: and also a FIFO I/O scheduler) Why does this require 36 cores today??
Re: Achieving 100k connections per second with Elixir
#68Re: Achieving 100k connections per second with Elixir
#69I can handle 120k connections per second with my custom made, highly optimized multiprocess C++ server. But the main problem is business logic. Just make 2 SQL queries to MySQL on each HTTP request and look at how it will degrade.
Re: Achieving 100k connections per second with Elixir
#70This article is quite good, especially part about bottleneck caused by single supervisor in ranch. However I have to say that title is a bit misleading because all of this has nothing to do with Elixir, it's all about Linux kernel and Erlang, cowboy and ranch are written in Erlang. Having said that, I will add that I think it is good to have Elixir.
Presumably they were using cowboy through Elixir. It's not hard, the module is just called :cowboy instead of cowboy.