5 ms·

This might be slightly off topic, but what are the others in this same space?

nicoburns 7y ago
Presumably everything at the top of the list: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=...
bhauer 7y ago
In the Round 18 Plaintext results that the OP linked to [1], you can see a pretty clear convergence at ~7 million requests per second, which I've screen captured in [2]. [1] https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=... [2] https://www.techempower.com/images/misc/converge.png https://www.techempower.com/images/misc/converge.png
- GonzaloQuero 7y ago
  Thanks!
- jxcl 7y ago
  How can you tell how each test is bottlenecked? Is it something as simple as saying that if the processor isn't at 100% utilization then the bottleneck is somewhere else? I read a long time ago about how the linux kernel handled incoming packets in a really inefficient way that led to the network stack being the bottleneck in high performance applications. Is that no longer true? I'd love to learn more about this whole area if anyone has any good links.
  - wmf 7y ago
    In this case you'd want to discover a network bottleneck by looking at network utilization directly using a command like `sar n DEV 1`. (from http://www.brendangregg.com/Articles/Netflix_Linux_Perf_Analysis_60s.pdf http://www.brendangregg.com/Articles/Netflix_Linux_Perf_Anal... ) It's generally possible to go 3x-10x faster than Linux if you make some tradeoffs like dedicating cores to polling. See https://www.usenix.org/node/186147 https://www.usenix.org/node/186147 and https://wiki.fd.io/view/VPP/What_is_VPP%3F https://wiki.fd.io/view/VPP/What_is_VPP%3F Moore's Law excuses a lot of sins, however, so on the latest servers Linux is probably adequate up to 100 Gbps for most use cases.
  - pnako 7y ago
    Well, to start with you can actually compute the optimal number of packets per second, if you know the bit rate and the packet size. https://packet.company/ethernet-statistics https://packet.company/ethernet-statistics So the theoretical optimum is 14.88 Mpps (millions of packets per second). That's with the smallest possible payload. You need to divide that by two because the test involves both a request and a response, which gives you 7.44 million requests per second as the theoretical maximum. The best tests max out around 7 M rps. This gives an implied overhead of about 6%, which corresponds to the HTTP overhead.
    - Hikikomori 7y ago
      Why would you divide by two? Tx/Rx are separate.
      - pnako 7y ago
        You're right. But I assume the benchmark basically implements a ping-pong game instead of DoSing the server to see how many requests actually survive (I could be wrong).

Presumably everything at the top of the list: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=...

bhauer 7y ago

In the Round 18 Plaintext results that the OP linked to [1], you can see a pretty clear convergence at ~7 million requests per second, which I've screen captured in [2]. [1] https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=... [2] https://www.techempower.com/images/misc/converge.png https://www.techempower.com/images/misc/converge.png

GonzaloQuero 7y ago
Thanks!
jxcl 7y ago
How can you tell how each test is bottlenecked? Is it something as simple as saying that if the processor isn't at 100% utilization then the bottleneck is somewhere else? I read a long time ago about how the linux kernel handled incoming packets in a really inefficient way that led to the network stack being the bottleneck in high performance applications. Is that no longer true? I'd love to learn more about this whole area if anyone has any good links.
- wmf 7y ago
  In this case you'd want to discover a network bottleneck by looking at network utilization directly using a command like `sar n DEV 1`. (from http://www.brendangregg.com/Articles/Netflix_Linux_Perf_Analysis_60s.pdf http://www.brendangregg.com/Articles/Netflix_Linux_Perf_Anal... ) It's generally possible to go 3x-10x faster than Linux if you make some tradeoffs like dedicating cores to polling. See https://www.usenix.org/node/186147 https://www.usenix.org/node/186147 and https://wiki.fd.io/view/VPP/What_is_VPP%3F https://wiki.fd.io/view/VPP/What_is_VPP%3F Moore's Law excuses a lot of sins, however, so on the latest servers Linux is probably adequate up to 100 Gbps for most use cases.
- pnako 7y ago
  Well, to start with you can actually compute the optimal number of packets per second, if you know the bit rate and the packet size. https://packet.company/ethernet-statistics https://packet.company/ethernet-statistics So the theoretical optimum is 14.88 Mpps (millions of packets per second). That's with the smallest possible payload. You need to divide that by two because the test involves both a request and a response, which gives you 7.44 million requests per second as the theoretical maximum. The best tests max out around 7 M rps. This gives an implied overhead of about 6%, which corresponds to the HTTP overhead.
  - Hikikomori 7y ago
    Why would you divide by two? Tx/Rx are separate.
    - pnako 7y ago
      You're right. But I assume the benchmark basically implements a ping-pong game instead of DoSing the server to see how many requests actually survive (I could be wrong).