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

101–110 of 122 posts

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

#101

Post by ricardobeat »

batista wrote: post #90
fruchtose wrote: post #60

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

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

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

#103

Post by trimbo »

zafriedman wrote: post #100
binarymax wrote: post #16

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

I'm going to ask a dumb question as someone who is just learning node. What's wrong with serving assets out of public/ in an Express app? Why would someone not want to do this?

For the vast majority of sites that ever hit the web, yeah, it will probably be fine. So go ahead and have fun learning node and do it however, you can always fix it later if the site gets overloaded.

At some volume though, you want to do what the grandparent recommends -- front your application server with nginx, apache, or something. Otherwise serving up static assets is taking away resources that should be spent on the application. Consider if you have a page with 5 images, 5 JS files and 5 CS files for each page created. That means you're serving 15 static assets for every 1 dynamic asset you'd really want to use Node for. While Node can still be "good enough", it is not spending its time doing the stuff you really want to use it for in the first place. A dedicated piece like nginx goes much further.

And also use a CDN :p

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

#104

Post by drostie »

soc88 wrote: post #86
tferris wrote: post #29

Earlier quoted context omitted.

> It does this by forcing the entire ecosystem to be async too (including things like database drivers). Yes, that's exactly Node's main selling proposition everybody forgets when presenting their next Node.js

I would call it "node.js's largest implementation issue". It is not that JavaScript gives you another choice, while you make it sound like it was a principled decision. Other platforms/languages have real concurrency constructs and don't suffer node's limitations.

Well, no, you could have done all of these things synchronously, and in fact JS would have preferred it because JS is intrinsically single-threaded. Ryan Dahl's stated inspiration for Node was that he struggled with a certain slowness in Ruby because it blocked for everything, so he tried to build an entire language that simply wouldn't let you sleep(). You can go listen to his talks; they're on YouTube. It was a principled decision.

I don't know whether making JS single-threaded was a principled decision -- if anything it was presumably the KISS principle at work. However, it was actually a ridiculously nice choice to offer a single-threaded-asynchrony model. It sometimes gets in the way rather obtusely -- Firefox can still (if very rarely) fail to introspect and then crash when some ad script on your page goes into an infinite loop! -- but on the whole, it is very nice to always know that while I'm in this function, modifying this variable, nobody else can interfere.

With that said, I also think that the lack of good concurrency planning is indeed missing, and that it will probably enter the language at a future time.

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

#105

Post by simonw »

pron wrote: post #82
simonw wrote: post #79

Earlier quoted context omitted.

I imagine you mean that servlets are the most performant web stack, not the most scalable web stack. Scalability != Performance.

Well, I'm sure it's easy to beat servlets with a load that requires only one thread with a simple enough computation model. Servlets (and any truly multithreaded solution) trades single-thread performance with the ability to scale with the number of cores. That's what I meant. So I would think that given a heavy load on a many-core machine with interesting enough computations, nothing could beat servlets' performance…

My apologies - it's clear you were talking about scaling performance with additional cores, which is entirely the right usage of the term.

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

#106

Post by cbsmith »

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…

The polling loop and I/O interfaces with Vert.x is integrated in to the VM, whereas with Node.js, you'll calling out to libuv/libev/etc. That gives the JVM an advantage. Really, how much actual JavaScript code is V8 JIT'ing at all?

Really what you are comparing here is the efficiency of the paths between the two JavaScript engines and their polling I/O libraries, more than any JIT work (and let's face it, even if we were comparing JIT work, the Sun JVM has had a lot more time to tune and tweak than V8 has). In Node's case, it's talking through libuv, which means it has to transition in-and out of the V8 engine's runtime and in to a C runtime. Even if the C code is super zippy, that's costly. For Vert.x though, all the I/O and polling is integrated in to the runtime/VM/JIT. That's kind of nice.

An interesting way to test what I'm suggesting would be to do the same test with unix domain sockets/named pipes as the transport instead of TCP. The JVM doesn't have a native implementation, so it'd have to call out through JNI. I'd wager even odds it ends up slower than TCP on localhost.

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

#107

Post by ithkuil »

pron wrote: post #77
ithkuil wrote: post #76

Earlier quoted context omitted.

I don't think this is true. Nodejs uses epoll/kqueue/select etc to multiplex access to multiple file descriptors from a single main thread. The async API is actually a price to pay (spaghettification). For example, the go language took a different approach: it created a cheap thread-like construct which doesn't incur in the biggest overhead of classical threading (namely pre-allocated linear stacks and context switch…

Yes, but at the end of the day, underneath it all, you gotta have threads because that's what the hardware understands. Even if you use hardware interrupts to detect IO, you still need a plain old thread to handle it. The only difference between various languages and runtimes is how you distribute tasks among the threads. Some environments provide green threads that have a partial stack, but even they are handed off…

I feel that the cause of misunderstanding lies in the fact that "thread" in this context is usually means "thread based IO", which means that when a thread issues a IO request it remains blocked until the IO request returns, leaving CPU time to other threads. All this regardless how many processors you have; it works perfectly fine with single processors.

Async IO is different, it's a different patter of access to IO and as such it's orthogonal to any threading or multiprocessing that's going on in order to actually do stuff in response to that IO.

> It's been found that if you employ only a single thread (that can run any number of tasks) you get a performance boost over using a larger threadpool under some conditions, but a single thread wouldn't let you scale by taking advantage of all processors.

Indeed. Nodejs solution to this problem is to have a cluster of nodejs processes and a dispatcher process on top. So multiprocessing is done the "old way".

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

#108

Post by pron »

ithkuil wrote: post #107
pron wrote: post #77

Earlier quoted context omitted.

Yes, but at the end of the day, underneath it all, you gotta have threads because that's what the hardware understands. Even if you use hardware interrupts to detect IO, you still need a plain old thread to handle it. The only difference between various languages and runtimes is how you distribute tasks among the threads. Some environments provide green threads that have a partial stack, but even they are handed off…

I feel that the cause of misunderstanding lies in the fact that "thread" in this context is usually means "thread based IO", which means that when a thread issues a IO request it remains blocked until the IO request returns, leaving CPU time to other threads. All this regardless how many processors you have; it works perfectly fine with single processors. Async IO is different, it's a different patter of access to IO…

In that case, Java gives you both options: blocking IO and non-blocking, polling IO. Netty can use both, but most people use it with the non-blocking option. Experiments have shown that sometimes one is faster and sometimes the other.

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

#110

Post by purplefox »

nfriedly wrote: post #91
DTrejo wrote: post #80

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

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 reply on HN