Live data from Hacker News

Achieving 100k connections per second with Elixir

stressgrid.com

11–20 of 117 posts

Re: Achieving 100k connections per second with Elixir

#11
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??

If you read the article, in the third or so paragraph.

> What this means, performance-wise, is that measuring requests per second gets a lot more attention than connections per second. Usually, the latter can be one or two orders of magnitude lower than the former. Correspondingly, benchmarks use long-living connections to simulate multiple requests from the same device.

Re: Achieving 100k connections per second with Elixir

#12
post #8
post #6

Earlier quoted context omitted.

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

Was your benchmark for requests/sec or connections/sec?

Single-request connections. Response required consulting memcached and updating it from postgres if out of luck, which was very rare but still needed (and patching then-existing postgres C client to be async aware was an undertaking)

Re: Achieving 100k connections per second with Elixir

#13
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.

Re: Achieving 100k connections per second with Elixir

#14
post #10
post #6

Earlier quoted context omitted.

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

Duh. Of course a C event loop while be faster at accepting connections, that's not the point of the article.

They boast only accepting 100K connections per second, not pushing back a meaningful response?

Why this is even here then?

Re: Achieving 100k connections per second with Elixir

#16
post #9
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.

Did starting more acceptors than the number of cores make any difference?

I'm not related to the author(s) of the article in any way. Just a slightly more careful reader than OP ;)

Re: Achieving 100k connections per second with Elixir

#17
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.

"is a bit misleading because all of this has nothing to do with Elixir" Stressgrid is written in elixir though, https://gitlab.com/stressgrid/stressgrid

Re: Achieving 100k connections per second with Elixir

#18
> What this means, performance-wise, is that measuring requests per second gets a lot more attention than connections per second. Usually, the latter can be one or two orders of magnitude lower than the former.

does anyone know how does 100k connections compare with other servers?

Re: Achieving 100k connections per second with Elixir

#19
post #11
post #6

Earlier quoted context omitted.

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

If you read the article, in the third or so paragraph. > What this means, performance-wise, is that measuring requests per second gets a lot more attention than connections per second. Usually, the latter can be one or two orders of magnitude lower than the former. Correspondingly, benchmarks use long-living connections to simulate multiple requests from the same device.

Your point being? I was talking of single-request connections.

Re: Achieving 100k connections per second with Elixir

#20
>Finally, the connections per second rate reaches 99k, with network latency and available CPU resources contributing to the next bottleneck.

Can someone educate me on what they might talking about here ? CPU is ~45% in their final graph. I don't know what network latency means in this context though. Roundtrip for a TCP handshake ? That seems unlikely.

Post reply on HN