4 ms·

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 n

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.

Strom 10y ago
First off it uses HTTP/1.1 pipelining. There's not a single actively developed browser in existance that supports HTTP/1.1 pipelining out of the box. [1] Thus you certainly can't use this for web development. 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_in_web_browsers https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation...
- z3t4 10y ago
  basically all apps now a day communicate via http to avoid firewalls.
- nitely 10y ago
  It's useless for other reasons. Pipelining and non-idempotent methods (i.E POST) don't go togheter.
Yokohiii 10y ago
Having lower latency and bigger throughput is always good. But will it have any impact in real apps? Memory management and IO aren't gone just because your http stack is fast. The average node app will probably fall way behind just because of GC.
- coldtea 10y ago
  >Having lower latency and bigger throughput is always good. But will it have any impact in real apps? 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.
quickben 10y ago
Well, exactly that. They can open a million sockets a second. Handling that many requests is entirely different bulpark. You have to account for a lot other factors: transaction types, server loads, what kind of rampup the load had, etc. 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.
- Kiro 10y ago
  With that logic you can't benchmark anything.
- coldtea 10y ago
  >Well, exactly that. They can open a million sockets a second. Handling that many requests is entirely different bulpark. 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.
  - quickben 10y ago
    But nodejs network, last time I checked, ran on one thread. Opening sockets doesn't run in vacuum. What you said may be true for multithreaded apps, but resources are shared in nodejs.
    - coldtea 10y ago
      >But nodejs network, last time I checked, ran on one thread. 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.
NathanKP 10y ago
It's useless because a real world application will take some non trivial amount of system resources to actually serve the request and that is going to be the actual bottleneck, not the HTTP module. 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.

Strom 10y ago

First off it uses HTTP/1.1 pipelining. There's not a single actively developed browser in existance that supports HTTP/1.1 pipelining out of the box. [1] Thus you certainly can't use this for web development. 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_in_web_browsers https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation...

z3t4 10y ago
basically all apps now a day communicate via http to avoid firewalls.
nitely 10y ago
It's useless for other reasons. Pipelining and non-idempotent methods (i.E POST) don't go togheter.

Yokohiii 10y ago

Having lower latency and bigger throughput is always good. But will it have any impact in real apps? Memory management and IO aren't gone just because your http stack is fast. The average node app will probably fall way behind just because of GC.

coldtea 10y ago
>Having lower latency and bigger throughput is always good. But will it have any impact in real apps? 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.

quickben 10y ago

Well, exactly that. They can open a million sockets a second. Handling that many requests is entirely different bulpark. You have to account for a lot other factors: transaction types, server loads, what kind of rampup the load had, etc. 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.

Kiro 10y ago
With that logic you can't benchmark anything.
coldtea 10y ago
>Well, exactly that. They can open a million sockets a second. Handling that many requests is entirely different bulpark. 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.
- quickben 10y ago
  But nodejs network, last time I checked, ran on one thread. Opening sockets doesn't run in vacuum. What you said may be true for multithreaded apps, but resources are shared in nodejs.
  - coldtea 10y ago
    >But nodejs network, last time I checked, ran on one thread. 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.

NathanKP 10y ago

It's useless because a real world application will take some non trivial amount of system resources to actually serve the request and that is going to be the actual bottleneck, not the HTTP module. 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.