For some servers wall time significantly exceeds the expected duration of the test when fasthttp client is used about bombardier

[codesenberg]

Thanks for the info, @cyrusmsk.

I did some troubleshooting and my current understanding is that this has more to do with the HTTP client used, rather than with the server used. With --fasthttp (default client) the test indeed can take unexpectedly long to complete, but with --http1 & --http2 the test usually completes within ~--duration + --timeout + time to prepare the test + time to shutdown the test (last 2 usually don't take long, i.e. couple seconds at most).
Not sure what causes shutdown delay for fasthttp. Could be that some timeouts/deadlines we set are not respected by the client or that bombardier is not setting up the client so that they are respected. Will have to dig deeper.

The issue itself seems to be more of an annoyance and thankfully there is a workaround.

[codesenberg]

Hard to tell really.

http://localhost:3000/

Since it would seem that you know what kind of server makes it possible to get such results, care to elaborate on this a bit?

[cyrusmsk]

Yes, sure. I will double test results with native Darwin and Linux(Docker) until the weekend.
The source code and previous results are available here: https://github.com/cyrusmsk/d_http_benchmark/tree/main

The only thing that currently build instruction optimized for Docker run. To run locally on macOS it's better to remove "flags-ldc" row from dub.json file.