Look into better ways for measuring performance.

wrk is an ok tool for measuring throughput, but it can be misleading. The issue of only looking at throughput is that you ignore latency. So a server may have a higher throughput than another but at a much worse latency.

I think instead of measuring throughput, you get much nicer and more meaningful results when you try to figure out the max requests per second a framework can handle while also staying below a specific latency. For example, max req/s with at most 300ms 99.9% latency. This ensures that all the frameworks are competing against the same bar and gives more meaning to the results.

If you want more details on why you should measure latency with throughput, here are a few good articles: Your Load Generator Is Probably Lying To You and Everything You Know About Latency Is Wrong. Also, this is an amazing talk on the issue: How NOT to Measure Latency.

I would suggest that this repo look into defining a latency goal and then measuring the max throughput a framework can get to while meeting the goals. To go along with that, I would suggest that the the repo use either wrk2 or vegeta for measuring. Vegeta tends to get better and more accurate results, but is more resource intensive. It is more likely to cause the client computer to run out of resources when trying to benchmark. I also wrote a wrapper for vegeta that simply does a search for the max throughput that is possible for a specific latency target. It is called vegeta-break.

No repository files, tests, or benchmark entry points are named. Start by locating the current throughput-measurement setup and reviewing how it invokes wrk, then compare whether wrk2 or vegeta can support a defined latency target. Done would require an agreed latency goal and benchmark results reporting maximum requests per second while meeting it.