I don't understand why you would say this benchmark is useless. As we can see from the wiki, the core http module can handle just 65k requests/second. But the new websockets approach can handle a million requests/second. I think this is astonishing.
Secondly, the post doesn't seem to mention this but I'm willing to bet that this microbenchmark, like all others like this, are doing all these million requests from a single client that's located on the same machine.
How many real world use cases are there where a single localhost client will do a million requests per second and also supports HTTP/1.1 pipelining?
--
[1] https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation...
Just because the word "million" seems impressive, it doesn't mean much. There is a difference between a million photons hitting a tree and a million meteors hitting a tree. The rest of the context is important.
That's both a trivial AND useless information. The request handler could do an expensive 2-hours operation that uses 100% of a core for all we know. That's up to the web programmer to optimize.
The http-lib programmer, on the other hand, should optimize, and give data, for exactly what it does, nothing more, and nothing less.
People seem to conflate those responsibilities all the time when they see a benchmark. A http-parser benchmark's role is not to tell you how fast your app will serve.
What you said may be true for multithreaded apps, but resources are shared in nodejs.
It can multiplex operations at the event level however, and all its common libs follow that model. So while it might run "on one thread" it can leverage the CPU quite efficiently. And you can always run multiple processes.
So for example lets say your application has to parse a JSON POST body, talk to a database, and then serialize a JSON response. You'll be lucky to get 1k reqs/sec throughput. At that point it actually doesn't matter whether your http module can handle 65k req/sec or 1 million reqs/sec because you will never be able to serve that many anyway. If your http module did manage to pick up 65k reqs/sec from clients they would all just timeout.
These benchmarks reach those numbers by doing nothing but serving a tiny static string, but that's not what happens in real life. In summary these benchmarks are interesting, but its optimization in an area which isn't actually the thing holding back most backend servers from serving more requests per second.
Obviously yes.
>Memory management and IO aren't gone just because your http stack is fast.
Obviously yes again. But they are helped by it.