Ah, I think I understand now, we are bombarding the server in a H/1.1 pipelined approach so basically not waiting for server response to send the next request and theoretically using infinite pipelined depth as we never really check any response and simply jam the server with as many requests as possible. That would explain the results - the issue with that is that we don't really check if the server is able to process the extremely high number of requests and most of them are likely just lost and never processed by the server - so we are basically measuring the tool output capability not the server performance.

I can see in the results .txt that only a small portion of the sent requests actually result in a response, also not every server supports H/1.1 pipeline so they will flush once per request (typical workload), servers that support pipeline will have way higher throughput