How is wrk-bench example meant to be exercised? about tokio-uring

[FrankReh]

Thanks for the info. I've been working with my own fork of rewrk to stress the wrk-bench and a new wrk-bench-multishot. I added an HdrHistogram to show all the connection latencies. One day, we should have a rewrk that is based on tokio-uring too.

The biggest reason I made changes to rewrk was that in its current state, it is designed to measure throughput and latencies of messages and responses. It can't measure the rate of accepted connections that close themselves immediately after responding with a single message - well it can, but the numbers it calculates are very misleading.

The best throughput is being achieved when the rewrk batches its connect futures a few at a time, with a 1ms interval between batches. That keeps the kernel TCP setup mechanism happy between my two kernels and the latency for individual setups is low - the number of TCP accepts possible per second is high.

At this point, I don't know if it would still be called ReWrk since these new flags make it very accept/stress specific. Tokio makes it very easy to write efficient stress tests though, I'm glad you pointed me to the rewrk app.

[Noah-Kennedy]

This is a stupid, silly benchmark I wrote that is intended to be used in conjunction with (wrk)[https://github.com/wg/wrk] or (rewrk)[https://github.com/lnx-search/rewrk].

This is really only intended for internal use when developing on this repo. It's useful for examining how different tweaks improve or worsen our throughput with a large volume of relatively small IO ops.