Live data from Hacker News

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

vertxproject.wordpress.com

31–40 of 122 posts

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

#31
post #22
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…

Non-existant ecosystem is a harsh assessment especially given the massive amount of java code our there. Any jar file can be used so the Java ImageIO package can easily be leveraged. It's early on for this tool chain, but all you have to do is get a 3rd party jar file in the class path of the server, and you can directly call Java methods from Javascript.

importPackage(java.io); var file = new File('/blah/blah/blah.txt');

Other languages would be equally easy as well. It's burried, but here is some relevant information from the docs on integrating 3rd party libs:

-cp The path on which to search for the main and any other resources used by the verticle. This is ignored if you are running an installed module. This defaults to . (current directory). If your verticle references other scripts, classes or other resources (e.g. jar files) then make sure these are on this path. The path can contain multiple path entries separated by : (colon). Each path entry can be an absolute or relative path to a directory containing scripts, or absolute or relative filenames for jar or zip files. An example path might be -cp classes:lib/otherscripts:jars/myjar.jar:jars/otherjar.jar Always use the path to reference any resources that your verticle requires. Please, do not put them on the system classpath as this can cause isolation issues between deployed verticles.

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

#32
post #28

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.

Not really. It shows that this benchmark is crap (likely benchmarking disk io versus disk io + some caching). Read Isaac's comment for more detail. He sums it up pretty well. No profiling info, using a custom test, no analysis besides some pretty graphs.

I have a hard time believing the JVM is really 10x faster than v8 for such a simple server.

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

#33
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…

Non-existant ecosystem is a harsh assessment especially given the massive amount of java code our there. Any jar file can be used so the Java ImageIO package can easily be leveraged. It's early on for this tool chain, but all you have to do is get a 3rd party jar file in the class path of the server, and you can directly call Java methods from Javascript. importPackage(java.io); var file = new File('/blah/blah/blah.t…

Thanks for the clarification.

Assumed I use this ImageIO package. Will it be nonblocking, concurrent and spread to all my cores automagically with Vert.x??

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

#34
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…

The value of this is far overstated. You can think of your server as being composed of async queues and thread pools, even in node. About the only thing in a stack that truly is async is connection handling via epoll. Mysql itself is a big threadpool, bounded by the number of cores and table locking.

The jvm has amazing threading support, doubly so if you use it with a language like scala or clojure. You can and should handle the connections asynchronously and use a thread pool for things like db access. It works well, people have done this with the jvm for years.

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

#35
post #33

Earlier quoted context omitted.

Non-existant ecosystem is a harsh assessment especially given the massive amount of java code our there. Any jar file can be used so the Java ImageIO package can easily be leveraged. It's early on for this tool chain, but all you have to do is get a 3rd party jar file in the class path of the server, and you can directly call Java methods from Javascript. importPackage(java.io); var file = new File('/blah/blah/blah.t…

Thanks for the clarification. Assumed I use this ImageIO package. Will it be nonblocking, concurrent and spread to all my cores automagically with Vert.x??

Since they are not limited by a single threaded VM, you would run those using the worker pools and communicate with them via an actor type model similar to erlang. So, modulo a small amount of verticle code to deploy your image processor, yes.

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

#36
post #33

Earlier quoted context omitted.

Non-existant ecosystem is a harsh assessment especially given the massive amount of java code our there. Any jar file can be used so the Java ImageIO package can easily be leveraged. It's early on for this tool chain, but all you have to do is get a 3rd party jar file in the class path of the server, and you can directly call Java methods from Javascript. importPackage(java.io); var file = new File('/blah/blah/blah.t…

Thanks for the clarification. Assumed I use this ImageIO package. Will it be nonblocking, concurrent and spread to all my cores automagically with Vert.x??

Not automagically, but java has some really good tools for helping. See the http://docs.oracle.com/javase/7/docs/api/java/util/concurren... package. Check the Executors section and you can easily distribute work via threads to all your cores. In fact, vert.x is using netty, which makes heavy use of threads along with async IO. You can do both.

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

#37
post #22
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…

You don't need to necessarily have non-blocking libraries to take advantage of the async I/O. Netty uses worker threads to prevent blocking the server event loop and I assume Vert.X does as well. You can do blocking JDBC queries, Redis, etc.

As far as concurrency, most libraries state in the docs what is threadsafe and what is not, so this is more or less "caveat emptor" and RTFM.

Vert.x has its own module subsystem which appears to package up .jar files and some glue code for the Vert.x-specific interface, but I assume you can call any included Java classes directly: http://vertx.io/mods_manual.html

(Interestingly enough, Vert.x uses Gradle for its build/dependency manager, but I guess wanted something more Node-like for its module system)

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

#38
post #32
post #28

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.

Not really. It shows that this benchmark is crap (likely benchmarking disk io versus disk io + some caching). Read Isaac's comment for more detail. He sums it up pretty well. No profiling info, using a custom test, no analysis besides some pretty graphs. I have a hard time believing the JVM is really 10x faster than v8 for such a simple server.

> I have a hard time believing the JVM is really 10x faster than v8 for such a simple server.

Honest question, why?

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

#39
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.

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

#40
Every. Single. Static. Benchmark. For. HTTP. Is. Bullshit. It's really as simple as that. Why?

Because the limiting factor in every scenario is the pipe. Not the CPU. Not the RAM. The internet connection.

Even the most miserable http server will saturate the pipe with static content.

These benchmarks boil down to mental masturbation and fanboism.

Post reply on HN