| HN Mirror

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

benfolred 2670 days ago

You are comparing apples and oranges.

They are purposely holding the connections around for 1+10%seconds. So first of all, it means that, for a rate of 100k conn/s, they are going to have around 200k open connections after a second. This already imposes a different profile than 100k single request connections per second.

You are also assuming that they need 36 cores to achieve 100k connections per second, which is likely not the case since they quickly moved the bottleneck to the OS. I am assuming they have other requirements that force them to run on such a large machine and they want to make sure they are not running into any single-core bottlenecks (and having a large amount of cores makes it much easier to spot those).

Thaxll 2670 days ago

I highly doubt you were able to do 100k connections/sec 10 years ago with the same hardware, you must be confused between requests/sec and connections/sec very different things.

rozap 2670 days ago

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.

jasonlotito 2670 days ago

> I was talking of single-request connection.

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

Yeah, what's being discussed here are connections without any i/o over them. Just an fd lingering somewhere in an epoll pool. Which obviuosly is even less taxing. So your point is?

kierenj 2669 days ago

..that you are comparing apples and oranges, like he said

StreamBright 2669 days ago

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.

lpgauth 2670 days ago

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?

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

Maybe the metrics were inadequate

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.

jacobn 2670 days ago

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)

jasonlotito 2670 days ago

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

jasonlotito 2669 days ago

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

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

kt315_ 2669 days ago

Author here. We tried number of acceptors that was 4x and 16x number of cores without any difference.

zambal 2670 days ago

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

dclusin 2670 days ago

skimming fail :(