Live data from Hacker News

Achieving 100k connections per second with Elixir

stressgrid.com

61–70 of 117 posts

Re: Achieving 100k connections per second with Elixir

#61
post #45

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.

So yeah, those are generally considered to be requests per second. Apples and oranges.

Re: Achieving 100k connections per second with Elixir

#62

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

That was a helpful and interesting article. Thanks.

Re: Achieving 100k connections per second with Elixir

#63

Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?

What does high concurrency mean?

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

#64

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

Highly depends on which libraries are you talking about. Essentially you cannot claim that Go will be faster. You can say that fasthttp is faster than Cowboy for a hello world application. Every real world application is much more complex and the stack's performance will be decided by its slowest element.

Re: Achieving 100k connections per second with Elixir

#65
post #51

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

Well one of the fastest HTTP library out there is rapidoid and fasthttp comes very close to it as well as actix-raw, hyper and tokio-minihttp. Erlang and Elixir is lagged behind with a non trivial margin.

Re: Achieving 100k connections per second with Elixir

#67
post #6
post #4

Earlier 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??

Nothing tells more about an engineer than the last undocumented unreproducible hello world micro benchmark conducted by her once and only once some years ago that beats a real world application in terms of req/s leaving out latency profile.

Re: Achieving 100k connections per second with Elixir

#69
post #68

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

That seems like a job for sharded databases and caches.

Re: Achieving 100k connections per second with Elixir

#70
post #5

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

Or `Cowboy` with `alias :cowboy, as: Cowboy` ;)
Post reply on HN