Linux extreme performance H1 load generator
gcannon.org
Linux extreme performance H1 load generator
1–10 of 18 posts
Re: Linux extreme performance H1 load generator
#2It really should be shameful to use unqualified adjectives in headline claims without also providing the supporting evidence.
Re: Linux extreme performance H1 load generator
#3What is the point of making up claims of "extreme" performance without any accompanying benchmarks or comparisons? It really should be shameful to use unqualified adjectives in headline claims without also providing the supporting evidence.
Re: Linux extreme performance H1 load generator
#4What is the point of making up claims of "extreme" performance without any accompanying benchmarks or comparisons? It really should be shameful to use unqualified adjectives in headline claims without also providing the supporting evidence.
did you scroll down?
Re: Linux extreme performance H1 load generator
#5Re: Linux extreme performance H1 load generator
#6Really stupid question from someone who doesnt know much about io_uring. Wouldn't doing all this i/o async make the latency measurements less accurate? How do you know when the i/o starts if you are submitting it async in batches of 2048?
Normally when I have run latency calculations in the past I run them from the perspective of the caller, not the server.
In most cases this is over the network, a named pipe or sock file.
I guess it should be possible to run multiple runtimes inside a program that run independently.
Re: Linux extreme performance H1 load generator
#7Really stupid question from someone who doesnt know much about io_uring. Wouldn't doing all this i/o async make the latency measurements less accurate? How do you know when the i/o starts if you are submitting it async in batches of 2048?
In fact, in all cases, you don't know when the syscall actually starts execution even with regular calls. The only thing you're sure is the kernel "knows" about the syscall you want. However, you have absolutely no indication on whether it started to run or not.
The real question is: are the classical measures accurate? All we have is an upper bound on the time it took: I fired the write at t0 and finished reading the response at t1. This does not really change with io_uring. Batches will mostly change one fact: multiple measurements will share a t0, and possibly a t1 when multiple replies arrive at once.
Is it important? Yes and no. The most important thing in such benchmarks is for the added delay to be consistent between measurements, and when it starts to break down. So it's important if you're chasing every µs in the stack, but not if your goal is lowering the p99 which happens under heavy load. In this case, consistency between measurements is paramount in order to get histograms and such that make sense.
Re: Linux extreme performance H1 load generator
#8Of course it needs to pre-generate the file and you need enough RAM for both the server running and caching the file but it needs almost zero CPU during the test run and can probably produce even more load than this io_uring tool.
Re: Linux extreme performance H1 load generator
#9What is the point of making up claims of "extreme" performance without any accompanying benchmarks or comparisons? It really should be shameful to use unqualified adjectives in headline claims without also providing the supporting evidence.
I personally never care about benchmarks presented, it's much better to use and see for myself so didn't think much about having a table with values there but I can understand how it may help.
Re: Linux extreme performance H1 load generator
#10Interesting, I made something similar years ago when io_uring wasn't around yet and it is just a couple threads blocking on sendfile: https://github.com/evelance/sockbiter Of course it needs to pre-generate the file and you need enough RAM for both the server running and caching the file but it needs almost zero CPU during the test run and can probably produce even more load than this io_uring tool.
So I just tried your tool and it just hangs, I see you're sending close requests, is this configurable to keep-alive, or even better, nothing? In Http/1.1 keep-alive/close is better not used at all, never try to enforce this as it is not mandatory.
A lot of servers just ignore the close and don't close the connection (like the one I am using) so this can be the issue I am having.