Could it be that wrk is falsifying results?

[MaxxDau]

I ran a test on /plaintext. With the original parameters (-t56 -c1024 pipeline 16), I got 20.23M req/s @278us to 20.19M req/s @330us, depending on the application settings.
However, when I provide wrk with more power and run -t70 -c1024, I get 36.40M req/s @218us to 38.25M req/s @251us.
The higher performance is only of secondary interest, as I am aware that wrk with -t56 cannot generate the load to utilise 56 cores of the application.

Rather, I am surprised that the latency is lower. My application was far from the CPU limit in the tests with -t56. So there is no reason for the high latency on the application side. And the subsequent tests also showed that with more performance for wrk, the latencies become lower.

Regardless of the techempower tests: When I test the performance of the application, I use -t = application vCPU cores x (1.5 - 2) depending on the test.

[MaxxDau]

There is no difference between CPU and memory. One thread from wrk has the same computing power as one thread from the application.
My PHP application is only a proof of concept. It is not optimised like many other applications listed at techempower. The PHP overhead is also not insignificant. Nevertheless, this is enough to push wrk to its limits. I therefore assume that many applications without this overhead will have exactly the same problem.

/json -c 512

Threads	Req/sec	Latency
t56	3.44M	0.12ms
t60	3.67M	0.11mm
t70	4.21M	0.10ms
t80	4.39M	0.098ms
t90	4.28M	0.095ms
t100	4.50M	0.10ms

/json -c 512 pipeline 16

Threads	Req/sec	Latenz
t56	18.2M	0.19ms
t60	19.6M	0.19ms
t70	22.1M	0.17ms
t80	24.0M	0.16ms
t90	25.0M	0.14ms
t100	24.8M	0.17ms

/json -c 512 vs -c 1024 (no pipeline)

Threads	c512	c1024
t56	3.44M	3.44M
t60	3.67M	3.71M
t70	4.21M	4.32M
t80	4.39M	4.83M
t90	4.38M	5.04M
t100	4.50M	5.06M