Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Achieving 100k connections per second with Elixir

stressgrid.com

Post reply on HN
Print view View original

31–40 of 117 posts

Re: Achieving 100k connections per second with Elixir

#31

Post by benwilson-512 »

makkesk8 wrote: post #23

Even if connections per second can be a magnitude or two lower than requests per second this result is still quite off by today's alternative. 14 core machine comparing .net core with other top webservers: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

A lot of folks are failing to read the article. They're intentionally holding each connection open for 1 whole second. This is a whole different ballgame than benchmarks where each connection is allowed to terminate as rapidly as it can send back a plain text response.

Re: Achieving 100k connections per second with Elixir

#32

Post by muststopmyths »

Qwertystop wrote: post #26
muststopmyths wrote: post #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.

The CPU graph peaks near 97% (teal line) at the time when connections-per-second are highest. Are you looking at the red? That's the version without the two patches.

oh yeah, you're right. I reversed the two in my head somehow.

Re: Achieving 100k connections per second with Elixir

#33

Post by ergl »

makkesk8 wrote: post #23

Even if connections per second can be a magnitude or two lower than requests per second this result is still quite off by today's alternative. 14 core machine comparing .net core with other top webservers: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

That's measuring reqs/s, and as you said, if conns/s is an order of magnitude or two less, that's 700k, or 70k conns/s, which is right around what this post finds.

Re: Achieving 100k connections per second with Elixir

#34

Post by dzik »

lstodd wrote: post #28
dzik wrote: post #21

Earlier quoted context omitted.

Would you mind sharing the details? (URL maybe) I think limiting factor might be not number of cores and outside of erl scope, that is eth card they used, network infrastructure, etc. Even Elixir could be something that impacts the tests.

There is no url summing the details unfortunately. The work in some unknown state is at https://code.google.com/archive/p/coev/ Without the business logic (which was in django IIRC) and deployment details, obviously. Very outdated and some later patches might be missing. No one was interested, you see. I'd be surprised if there were problems with network, and if there were, that should have been obvious in the metric…

Sorry, where do the authors claim they achieved >100k connections per second?

Re: Achieving 100k connections per second with Elixir

#35

Post by lstodd »

dzik wrote: post #34
lstodd wrote: post #28

Earlier quoted context omitted.

There is no url summing the details unfortunately. The work in some unknown state is at https://code.google.com/archive/p/coev/ Without the business logic (which was in django IIRC) and deployment details, obviously. Very outdated and some later patches might be missing. No one was interested, you see. I'd be surprised if there were problems with network, and if there were, that should have been obvious in the metric…

Sorry, where do the authors claim they achieved >100k connections per second?

I'm the author, and that's the truth.

Can't see how this can be replicated as a controlled experiment nowadays, unfortunately.

But if you define exactly what's a request, what's a response, and what the connection/response ratio is let's have a race.

Like, you set the parameters, and whoever serves that on lower-capability hardware wins. Py3 plus low-level C/Rust hacks vs Elixir, say.

Re: Achieving 100k connections per second with Elixir

#36

Post by jasonlotito »

lstodd wrote: post #19
rozap wrote: post #11

Earlier quoted context omitted.

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.

> I was talking of single-request connection.

Yes. Which is not what's being discussed here.

Re: Achieving 100k connections per second with Elixir

#37

Post by muststopmyths »

benwilson-512 wrote: post #31
makkesk8 wrote: post #23

Even if connections per second can be a magnitude or two lower than requests per second this result is still quite off by today's alternative. 14 core machine comparing .net core with other top webservers: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

A lot of folks are failing to read the article. They're intentionally holding each connection open for 1 whole second. This is a whole different ballgame than benchmarks where each connection is allowed to terminate as rapidly as it can send back a plain text response.

Good point. At first glance, holding the connection open for one second seemed a bit meaningless if they're touting connections/sec.

But since they are benchmarking Elixir, there is some amount of overhead involved in that framework's management of connections and requests. If I knew Erlang/Elixir, that would be a fascinating thing to explore.

Edit: I'm assuming the saturated CPU comes from Elixir and not the OS. It would be strange for 100k/sec to saturate the TCP stack with 36 cores.

Re: Achieving 100k connections per second with Elixir

#38

Post by Thaxll »

dnekencjfkerf wrote: post #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?

It's probably easy to do with Java / C# and Go, they're using a 36 cores machine to achieve that with fast CPU, meaning that you need 3000conn/sec per core, very doable with recent frameworks.

Re: Achieving 100k connections per second with Elixir

#39

Post by jasonlotito »

lstodd wrote: post #12
jacobn wrote: post #8

Earlier quoted context omitted.

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)

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

Re: Achieving 100k connections per second with Elixir

#40

Post by dzik »

lstodd wrote: post #35
dzik wrote: post #34

Earlier quoted context omitted.

Sorry, where do the authors claim they achieved >100k connections per second?

I'm the author, and that's the truth. Can't see how this can be replicated as a controlled experiment nowadays, unfortunately. But if you define exactly what's a request, what's a response, and what the connection/response ratio is let's have a race. Like, you set the parameters, and whoever serves that on lower-capability hardware wins. Py3 plus low-level C/Rust hacks vs Elixir, say.

That's the thing. You can always hack something in C to prove there is a better way for a specific task. In the past I did things like that just for fun. But in the real world it does not work like that. You buy into things as a whole, accepting their pros and cons as a whole. If you need to hack - change your tools.
Post reply on HN