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

Interesting results.<p>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.<p>What is surprising however, is that javascript on the JVM w/ vert.x is faster than V8 with node. In both cases I would assume not much JS is executed, since in Vert.x most of the executing code is still Java, with a tiny piece of JS scripting on top, and in the Node.js case, I was under the impression that most of the executing code would be the C code that powers its HTTP server.<p>Does anyone with knowledge of the node internals know what's going on here? Is Node's HTTP parser just slower? Is its reactor not as efficient?

Perhaps a dumb question: Are the headers the same? With so small files, the header layout is suddenly very important for your measurement.<p>I've seen my share of web servers which are very different in their compliance.

My comment: <a href="http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/#comment-14" rel="nofollow">http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-...</a>

A rigorous benchmark must seek to explain the difference in performance, not just hand-wave saying "such-and-such is faster". Otherwise, you have no way of validating (for yourself, let alone demonstrating to others) that it's not a misconfiguration or a flaw in your benchmark.

Just goes to show that when the node.js fad is over, the enterprise world will keep its high availability servers running on proven technologies.

This is consistent with a benchmark I did a while back comparing Netty vs. Node.js. Not surprising since Netty powers Vert.x. Netty is pretty amazing. 500K concurrent connections and not batting an eye.

According to the code, it actually does a file read on every request -- this is certainly suspicious because some implicit caching may significantly change the results.

With regards to Vert.x, it seems like really cool stuff.<p>On the blog post about version 1 being released it mentions being able to mix and match several programming languages. Does this mean you can use different libraries written in different languages in the same Vert.x server?

Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another.<p>There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.

Very exciting initial results. The JVM simply is the most optimized runtime available right now. And Java is the dynamic language with best performance. Can't fail to notice Ruby is the slowest even on JVM. If you continue on this path and refine your APIs to be more user friendly, this would be the next big asynchronous server out there!

In the test, the node code is actually calling an asynchronous function fs.readFile on every single request:<p><a href="https://gist.github.com/2650401" rel="nofollow">https://gist.github.com/2650401</a><p>Even with os caching there is still quite a bit of overhead there. Would be interesting to see the benchmarks run on the corrected code:<p><a href="https://gist.github.com/2650401" rel="nofollow">https://gist.github.com/2650401</a>

The streaming node.js example he wrote uses a blocking call. This is not the node way, and would cause a definite slow-down.<p>If you're worried about your programs containing rogue &#38; misbehaving code like this, I recommend you use <a href="https://github.com/isaacs/nosync" rel="nofollow">https://github.com/isaacs/nosync</a>

I'm interested to know how vert.x compares to industrial-strength "traditional" servlet containers. My guess is that vert.x would outperform them under certain conditions, but all in all they would scale better.<p>I believe servlets are still the most scalable web stack out there.

Don't serve static files with node. Use an nginx reverse proxy for your html/js/css assets.

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):<p><a href="https://gist.github.com/2652991" rel="nofollow">https://gist.github.com/2652991</a><p>and then I get the following results:<p>vert.x:<p>39890 Rate: count/sec: 3289.4736842105262 Average rate: 2958.1348708949613 42901 Rate: count/sec: 2656.924609764198 Average rate: 2936.994475653248 45952 Rate: count/sec: 3277.613897082924 Average rate: 2959.610027855153<p>node.js:<p>38439 Rate: count/sec: 4603.748766853009 Average rate: 4474.62212856734 41469 Rate: count/sec: 4620.4620462046205 Average rate: 4485.278159589091 44469 Rate: count/sec: 4666.666666666667 Average rate: 4497.515122894601<p>Making that change so they both store the file in memory and nodejs is 50% faster than vert.x.<p>This is using an m1.small instance on EC2, and both vert.x and nodejs only using a single core.

I wanted to know the benchmarks including luvit. Vert.x vs luvit vs Node.js <a href="https://github.com/luvit/luvit" rel="nofollow">https://github.com/luvit/luvit</a>

Why are they measuring requests/sec? Any server can accept connections at a high rate but what matters is responding in a timely manner.<p>I doubt the requests number too. Writing a dummy socket server (evented, threaded, ...) that just returns "HTTP/1.1 200 OK" will not get you anywhere close to 120k requests/sec. The system call becomes the bottleneck.

Are there any easy cloud platforms or whatever that support easy deployment for Vert.x?

Testing A against B. A is found to be faster.<p>People in the B community come out in outrage saying that the testing is flawed, that microbenchmarking is useless, that this and that. Rinse and repeat.

Quite interesting. Is the Vert.x API compatible with CommonJS and/or Node modules? If not, I think it will suffer from the same chicken/egg problem that WebOS had with apps.

JVM beating the shit out of Node.js? I guess that's not even slightly surprising to anyone outside the Node.js bubble.