3 ms·
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
by makkesk8 8y ago
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-saturating-10gbe-at-7-million-requests-per-second/ https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...
- deleted 8y ago[deleted]
- sergiotapia 8y agoThat's really exciting! As someone who dropped out of .NET entirely around the time ASP.Net MVC2 came out, where do you recommend I start looking into aspnet core / .net core? Do you still write core .net in visual studio? or can you use vscode?
- benwilson-512 8y agoA 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.
- muststopmyths 8y agoGood 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.
- makkesk8 8y agoTotally missed that. In that case it does make sense.
- ergl 8y agoThat'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.