I don’t trust techempower first of all, far too many libraries doing questionable things that would never ever be done in production in it.

Second of all, last I checked the rocket.rs code it’s using is forcing each request to come as a new tcp connection, which will significantly make it ‘look’ slower than most other libraries (the fact its even still as fast as it is, is quite impressive though). To simulate more ‘actual’ web usage all testing should be done with new tcp connections each time though.

Third, the rocket.rs version they are using is still using the old version of hyper pre-async, which though still fast is not anywhere near as fast as modern hyper (which is used by the nightly version of rocket, which is the one most people use of rocket anyway until the next big release).

That’s what so so many of the libraries in the benchmarks do though, they aren’t even remotely oriented for what would seem like real world use, optimized only for benchmarks.

Great question!

Part of the answer might be this GitHub comment by Rocket’s primary maintainer, especially the second item:

There are three reasons: [why Rocket was not part of the Techempower benchmarks at the time]

1. I personally believe that developers tend to misplace trust on benchmarks. As such, it might be a good thing that Rocket isn’t on there. Perhaps then the decision of which framework to choose can be based on what’s really important: ergonomics, productivity, security, and correctness.
2. Rocket doesn’t and won’t ever cater to benchmarks. That is, we won’t make design decisions or changes to Rocket just to be faster at a particular benchmark without further justification.
3. No one’s written/submitted to TechEmpower.

Of course, it would still be interesting to see what is happening here that makes Rocket less efficient for these particular microbenchmarks w.r.t. other frameworks, especially the other frameworks also written in Rust.

It’s a social problem, not technical, so not sure a random bunch of a few enthusiasts can help much. Maybe if we roll our own benchmarking harness. But that would entail huge technical voluntary work – and we must have people that mercilessly curate the submitted code so that it doesn’t just game the benchmarking metrics.