Vert.x (JVM async) vs Node.js Http benchmarks results

Post by batista » Thu, May 10, 2012, 9:49 AM UTC

ricardobeat wrote: post #101

batista wrote: post #90

Earlier quoted context omitted.

> Node.js is not a fad. It represents the first workable JavaScript-based server with mass appeal. The real story is that JavaScript is here to stay. Javascript yes. Node.js, not so much. >There have been other server-side JavaScript frameworks in the past, but none of them have taken off like Node.js. Javascript was not a fast language in the past, nor was it much used for anything more than the most basic dynamic h…

> nor was it much used for anything more than the most basic dynamic html stuff You seem to have missed Netscape Enterprise Server (1994), HaXe, Helma, AppJet, Aptana Jaxer, Narwhal/Jack, EJScript, RingoJS, Flusspferd, and ASP.

Post by tipiirai » Thu, May 10, 2012, 1:41 PM UTC

courtneycouch wrote: post #112

So a quick verification. The io is the difference between these two. The JVM is doing some caching somewhere, whereas the v8 engine is not. Making a small change to both (in order to ensure that both are using the exact same logic): https://gist.github.com/2652991 and then I get the following results: vert.x: 39890 Rate: count/sec: 3289.4736842105262 Average rate: 2958.1348708949613 42901 Rate: count/sec: 2656.924609…

Post by courtneycouch » Thu, May 10, 2012, 1:50 PM UTC

andrewvc wrote: post #2

Interesting results. While it's not surprising to me that the pure java implementation was far and ahead better since: 1.) Java's much faster than Javascript, and 2.) Netty (which Vert.x is based on), has been doing high performance async IO for years before node even existed in extremely high performance environments. What is surprising however, is that javascript on the JVM w/ vert.x is faster than V8 with node. In…

Post by nfriedly » Thu, May 10, 2012, 8:44 PM UTC

purplefox wrote: post #110

nfriedly wrote: post #91

Earlier quoted context omitted.

I had the impression that "Node.js (readfile)", and possibly "Node.js" meant the blocking call but that "Node.js (streams)" meant he was using something like fs.createReadStream(). But you're right, I don't see that anywhere in the posted source.

I've tested several combinations of blocking, non blocking, readFile, streams (pipe) and using chunked transfer encoding. Results vary a little but all way below the Vert.x results. See blog post for the stats.

Post by joncooper » Thu, May 10, 2012, 9:55 PM UTC

sehugg wrote: post #43

andrewvc wrote: post #2

Interesting results. While it's not surprising to me that the pure java implementation was far and ahead better since: 1.) Java's much faster than Javascript, and 2.) Netty (which Vert.x is based on), has been doing high performance async IO for years before node even existed in extremely high performance environments. What is surprising however, is that javascript on the JVM w/ vert.x is faster than V8 with node. In…

I would also be interested in the internals. I'd expect JS + a small C event loop to outperform compiled JVM code + lots of async Java I/O libs (for a micro benchmark, at least). But there's no question Netty is fast even on a non-benchmark. I'm using it for a long-polling server with upwards of 100K connections, and my CPU doesn't go much over 5%. Besides memory usage, the main limitation has been proper kernel conf…