Thanks for feedback, applied some simpler UI/UX with zebra pattern tables but yea it is quite rough designing these tables that pack so much information in them.
Unfortunately I might have to agree that the UI/UX isn't the strong point, as expected of a website built by a firmware developer using AI tools' help, I would appreciate any feedback on how to improve it though, regardless, the tough part on a project like this is what is invisible to the eye, stable hardware/harness and reviewing PRs in 20 different languages/technologies to keep the leaderboard competitive.
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
I ran into some lua erros and fixed them, eventually I got it running with -shutwr but the results are basically impossible
----------- Summary ----------
Successful connections: 8 out of 8 (0 failed).
Total bytes sent . . . . . 2599999960.00 B
Total bytes received . . . 82520.00 B
Benchmark duration . . . . 85.94 ms
Send throughput . . . . . 30252779546.89 B/sec
Receive throughput . . . . 960176.69 B/sec
Aggregate req/second . . . 93085476.96
The received data is too low. Also 93 million requests per second, the only way this is possible is due the fact that the load generator is not waiting for the server response and processing it. But I guess this is expectable since there might be some issues as I am using a much more recent kernel than you did when building this
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.
I agree, I'll try adding some. We use the tool on a benchmarking platform so we run this thing hundreads of times daily and did dozens of tests against pretty much every other load generator (that I know of). Numbers are also always tied to the hardware where you run it and typically benchmarks provided by the maintainer himself are always biased and won't match what you get though.
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.