Reactor-based framework versus Node.js streaming | Hacker News Reader

Reactor-based framework versus Node.js streaming

gist.github.com

18 pointsKynlyn7 comments

"I found something faster than Node.js"

Why do people treat this as such a discovery? Where did Node claim to be the fastest solution to everything?

The only answer I can think of is that people feel threatened by node.js for some reason, and constantly feel the need to criticize it for not being the best at everything.

If you want to serve a 1mb file a million times, without caching it, or using sendfile, yeah, node will probably be slower compared to other things. It gets really old seeing posts like these.

The worst part is that they all end up showing their multicore program is faster than a single threaded node program. I haven't seen a single one use cluster.

Actually, it looks like the Java code is doing basically all the work using the sendfile(2) system call, but the node.js code is using its stream abstraction over file reads and socket writes. This benchmark proves exactly one thing: zero-copy networking system calls can make things faster. It doesn't say anything about the JVM or V8 except that neither is absolutely pathological for this.

Perhaps the author of the benchmark will assume that I'm only saying this because I am -- to quote his closing section -- a "dogmatic JVM-hater". Without deigning to reply to that notion, I will point out that preemptively smearing people who would disagree with you is rhetorically rude and generally not a good idea if you want to become right about things.

Having seen this kind of articles over and over in the past, I can't help but wonder why people keep on producing benchmarks to evaluate the capabilities of different servers/languages/frameworks/designs.

Unless the person producing the code or setup for the comparative benchmarks is an expert in all the fields he's comparing and handcrafting every single byte to perfection, it WILL all boil down to respective members of said communities pointing just how skewed, unprofessional and unfair the benchmark is.

There's no value to extract from such poney shows most of the time because it generally reduces complex concepts to mere numbers and metrics, with the additional task of managing to handle all the different setups, flags and whatnot in a way that doesn't create an outcry.

Interesting, but how is this different than Netty?

I'll admit, netty's interface is annoying, but that aside, from a perf perspective does this offer anything?

From a performance perspective, you can split the work here into two parts:

1. Reading and parsing HTTP requests, miscellaneous book-keeping.

2. Transferring a (cached) 1 MB file to a socket.

Netty is plenty fast at #1. At #2, both the Java/Groovy code in this benchmark and the corresponding code using Netty (versions >= 3.2.0) will be doing essentially the same thing: they will have the kernel do a zero-copy write from the filesystem cache directly to the socket. (The node.js version given here repeatedly copies from the filesystem cache into a buffer in its heap, and then writes that to the socket. This involves more memory copying and context switching. Neither Netty nor the author's own framework has this issue.)

So, I doubt there would be any significant performance advantage over Netty.

Just contribute to Netty, Finagle or Akka depending on the style you like.

Reply on news.ycombinator.com