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

51–60 of 122 posts

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

#51

Post by rabbitfang »

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, ...)

+1 for Scala

Might be nice to also see a FAQ about the differences between vert.x and Play 2

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

#53

Post by wh-uws »

mikeheath wrote: post #26
wh-uws wrote: post #23

Earlier quoted context omitted.

But be mindful though you always have to look very carefully at benchmarks. I don't think these are speed tests. Just number of connections that can be handled

I think you need to go back to the benchmarks and take a close look at the "Requests/Second" part. These benchmarks are nothing but speed tests.

Ah missed that

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

#54

Post by rabbitfang »

deelowe wrote: post #32
pjmlp wrote: 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.

Why would it surprise you that a statically typed language like Java on the highly optimized JVM is faster than Javascript?

Any benchmark you care to look at should clearly shows JVM is much faster: http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

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

#55

Post by ww520 »

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.

Requests per second implies downloading the complete request for each request.

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

#56

Post by pohl »

purplefox wrote: post #45
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

Could you clarify that? Are you saying that if the response is sent within the same second that the request came in that it contributes to the metric?

Or would a response that is sent 30 seconds after the request came in contribute to the metric too?

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

#57

Post by ww520 »

mbq wrote: post #7

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.

It includes a test with file streaming on Node.js, that bypass reading the file and write to socket via the Javascript loop completely.

Also file IO are heavily cached by the OS. You can bet that one file is read from memory most of the time. Disk IO is pretty much out of the equation.

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

#59

Post by ww520 »

pohl wrote: post #56
purplefox wrote: post #45

Earlier quoted context omitted.

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

Could you clarify that? Are you saying that if the response is sent within the same second that the request came in that it contributes to the metric? Or would a response that is sent 30 seconds after the request came in contribute to the metric too?

It doesn't matter whether a request straddles a second or not in a throughput measuring benchmark when you saturate the system. A client would only count a request when its request call has returned. Runs it for N minutes, count up how many requests have completed, then divide the total with the time and you got req/sec.

Besides the benchmark has run for a minute. I doubt each request lasts 30 seconds.

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

#60

Post by fruchtose »

pjmlp wrote: 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.

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. There have been other server-side JavaScript frameworks in the past, but none of them have taken off like Node.js. If Vert.x wins over the JavaScript crowd, then that's great, because coders will be able to write JavaScript.
Post reply on HN