I don't like ad-hoc benchamarks that do not attempt at all to investigate what was the cause of measured differences.<p>There are many factors that influence request processing time, language is only one of them. Web APIs are most often IO bound, so large differences between frameworks often indicate the IO is handled differently. From my experience, dynamic languages can easily handle HTTP requests below 10ms without any DB interaction, and out-of-a-box DB interaction that framework provide is often suboptimal. If you investigate, it can for example turn out that ORM runs several SQL queries for operations that could be performed with just one, or that it makes a separate DB connection for each request (looking at you Django).<p>Ruby 10x faster than Golang tells nothing.<p>Why is that there there is a big spike around 15,000 requests? If you investigate, you may discover that Puma by default creates 16 threads, and the benchmark simulates 20 clients (<a href="https://github.com/puma/puma" rel="nofollow">https://github.com/puma/puma</a>), so requests from 4 clients need to wait in queues. As a result, the benchmark may be comparing apples to oranges: code with no upper limit on number of concurrent requests, with code that can handle 16 concurrent requests.