
Reactor-based framework versus Node.js streaming - Kynlyn
https://gist.github.com/1444077
======
chjj
"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.

~~~
pjscott
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.

------
VeejayRampay
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.

------
andrewvc
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?

~~~
pjscott
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.

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

