Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

vertxproject.wordpress.com

Post reply on HN
Print view View original

41–50 of 122 posts

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

#41

Post by phillmv »

tferris wrote: post #22
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…

Very good point. V8 does heavy code optimization and Node.js http sever code should be well optimized as well. And maybe the load balancer for the multicore Node test isn't optimized enough. Thus, these results feel a little shady. Anyway, Vert.x was the trigger that I am finally downloading the JVM (JDK) to try Vert.x (and maybe later Clojure). But there's still one major drawback—the non-existant ecosystem. I know…

> Let's say I want to plugin some Java lib for image manipulation. How? And who will guarantee that these libs will be concurrent and/or non-blocking as well?

What? What do you mean by non blocking in this context?

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

#42

Post by halayli »

Why are they measuring requests/sec? Any server can accept connections at a high rate but what matters is responding in a timely manner.

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.

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

#43

Post by sehugg »

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

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

#44

Post by purplefox »

wickedchicken wrote: post #25
rapala wrote: post #9

Earlier quoted context omitted.

Ah, but is Vert.x web scale?

> Ah, but is Vert.x web scale? Better write a Mongo-backed fibonacci generator to check.

If you read the docs we specifically mention the "Fibonacci" farce.

Vert.x (unlike node) does not force you to do everything on the event loop. It has a hybrid model.

For things like long running calculations (e.g. Fibonacci) or calling blocking APIs, we support running them on a background thread pool so you don't end up doing stupid things on an event loop which are not appropriate for it.

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

#45

Post by purplefox »

halayli wrote: post #42

Why are they measuring requests/sec? Any server can accept connections at a high rate but what matters is responding in a timely manner. 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.

It's labelled badly, what is actually measured is req/resp per second.

I.e from request to corresponding response and how many of those it can do per second.

If you doubt the numbers please feel free to run them yourselves, all code is in github

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

#46

Post by purplefox »

baudehlo wrote: post #27
tferris wrote: post #22

Earlier quoted context omitted.

Very good point. V8 does heavy code optimization and Node.js http sever code should be well optimized as well. And maybe the load balancer for the multicore Node test isn't optimized enough. Thus, these results feel a little shady. Anyway, Vert.x was the trigger that I am finally downloading the JVM (JDK) to try Vert.x (and maybe later Clojure). But there's still one major drawback—the non-existant ecosystem. I know…

We know the java libraries are there for lots of things, but Node is all about async and handling thousands of connections. It does this by forcing the entire ecosystem to be async too (including things like database drivers). By using a Java JDBC database driver you're completely losing any async support. Same presumably goes for redis or Mongo drivers. You can do some of the work with threads and pooling, but it's…

Vert.x has a hybrid model.

It has both event loops and a background thread pool, so you can choose which to run your task on depending on what kind of thing it is.

E.g. it's stupid to run long running or blocking actions on an event loop.

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

#47

Post by anuraj »

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!

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

#48

Post by eropple »

purplefox wrote: post #17
jwingy wrote: post #5

With regards to Vert.x, it seems like really cool stuff. 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?

Yes indeed. You can mix and match Java, JavaScript, Ruby and Groovy in the same app. We hope to support more languages going ahead (e.g. Java, Scala, ...)

Once you get Scala, I'll be heading your way. :-)

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

#49

Post by eropple »

manuscreationis wrote: post #4
firefoxman1 wrote: post #3

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.

Seeing these numbers (although as the author states, the data needs to be taken with a grain of salt since he didn't try to set up a more "proper" test environment) really makes me want to take a serious look at vert.x, but what you mention here is my main concern. Node is a joy to use because of the NPM, and all the available libraries. I'd hate to lose that. That said, so long as it has a solid websocket api, and I…

> Node is a joy to use because of the NPM, and all the available libraries. I'd hate to lose that.

Maven's not bad at all (from a consumption perspective--from a dev perspective, it's a bit of a pain in the ass), and it looks like pretty much any Java library that doesn't do anything too insane should work just fine. (Disclaimer: never used vert.x myself, but I did a quick scan of the code.)

Post reply on HN