41–50 of 117 posts
> 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?
> 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.
The order of magnitude(s) differentiator for server performance really comes down to whether or not the architecture is blocking or non-blocking.
> 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?
On my desktop computer with a single thread, Ruby can handle about 2000/conn/s. I'm just going to check a single thread with a similar C++ implementation.
Earlier quoted context omitted.
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.
I offered to beat whatever you've done by tweaking the Py3 stdlib. Not by writing a plain C implementation.
If you for some reason doubt that this old python thing is of the real world - let me disappoint you. It was done because nothing else could do those 100K rps back then. And it did the thing for five years, until the whole stack was ditched.
Earlier quoted context omitted.
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.
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.
> 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?
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.
> 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?
With Python/uvloop I can easily get 10K-12K connections per second per core, so 36 cores will be fine with Python too.
Also, assuming it scales up linearly is a bit risky, although I agree with that kind of conn/s I am sure it will be sufficient.
Earlier quoted context omitted.
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.