I find these benchmarks to not be very valuable. Typically the bottlenecks are in the database, not in the web server/code. Even when it is in the code, optimizations only become truly valuable when you are at scale or doing something either horribly wrong or algorithmically unique.
It's interesting to take one piece of the stack and see how much abuse it can take, even if it's not necessarily reflective of real world behavior.
And what are you trying to say exactly? That you don't need optimizations until you do? How's that in any way helpful?
That said, I agree it's not a particularly useful benchmark.
Since this is on the JVM, SQL almost always means JDBC and JDBC is blocking so yes, SQL will in fact limit your concurrency.
We maintain a large number of connections (doing overlapping long polling) and we send the same information to each connection (about 30 times an hour at peak). Even if the query to produce that data was poorly optimised it's only being performed once and then the results pushed out to every connection.
I am the author of http-kit, also one of the authors of delicious China: http://meiweisq.com, trying to do some useful thing for our users (like realtime) with it. :)
Still, the ability to cheaply handle large numbers of concurrent connections is great for things like WebSockets and long polling where you aren't crunching data for every connection all the time. This is an async server, so it's well suited to such tasks.
> Add an endpoint with a poorly optimized SQL query: 20 concurrent connections.
Agreed. http-kit use threadpool to compute the response, try to minimize this a little.