5 ms·
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 f
by 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 agoWith 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 agoBut 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.