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

91–100 of 122 posts

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

#91

Post by nfriedly »

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.

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

#92

Post by eropple »

orefalo wrote: post #81
eropple wrote: post #48

Earlier quoted context omitted.

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

You already have Scala+Async IO+Netty, it's called play framework 2.0 http://www.playframework.org/

I've used it. Not a fan of many (most) of their design decisions, though it's better than the current alternatives.

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

#93

Post by cageface »

fruchtose wrote: post #60
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.

I think it's actually unfortunate that the first popular server-side JS framework is so tied to the async model. I'd be more likely to try it if it weren't.

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

#94

Post by baudehlo »

pron wrote: post #71
baudehlo wrote: post #27

Earlier quoted context omitted.

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…

Node's API is async. Under the hood everything is done via threadpools, same as in Java or any other stack. Your hardware knows how to run threads; that's all. Whether or not that's what's exposed to you as a programmer is a different story. You don't actually get a performance boost from Node being "async". Node's async abilities simply give you transparent access to threads that are otherwise unavailable with javas…

Umm, hardware knows NOTHING about threads. Threads give you a very fake view of the hardware. Everything about threads is an emulation over the hardware layer, hence why they have a large memory overhead.

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

#95

Post by alz »

In the test, the node code is actually calling an asynchronous function fs.readFile on every single request:

https://gist.github.com/2650401

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:

https://gist.github.com/2650401

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

#96

Post by baudehlo »

batista wrote: post #88
baudehlo wrote: post #27

Earlier quoted context omitted.

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…

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

> As an async environment it doesn't offer anything either new or too compelling

That isn't strictly true.

If you focus on the traditional scripting languages as your competition: Ruby, Python, PHP, Perl: Then you start to realise that Node.js does offer a similar language structure (dynamic, no compilation, etc), with the benefits of thousands of concurrent connections (which those languages will do with certain modules) but while forcing all the libraries to also be async (which those languages DO NOT do).

At my last job I had to build an SMTP server capable of scaling to 50k concurrent connections. Building this in Perl was fine, except for any library I wanted to use - all of the libraries were synchronous. So now I wrote Haraka, which Craigslist are now using as their incoming SMTP server.

If you compare all that to Java you get slightly less performance but probably lower memory requirements. And that's OK. Different strokes for different folks.

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

#97

Post by baudehlo »

pwpwp wrote: post #72
baudehlo wrote: post #27

Earlier quoted context omitted.

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…

> forcing the entire ecosystem to be async too You say that like it's a good thing. I'd much rather have the choice between async and sync.

The problem comes when you mix the two. Try it. Try scaling it (to a hundred thousand connections). I've done it and it doesn't mix.

Sure programming-wise it's nice to have sync. No argument there.

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

#98

Post by jroseattle »

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.

I wouldn't dismiss the node.js stack quite so easily. Those "proven" technologies you mention had to go through their own lifecycle of continued improvement.

I remember a time when my colleagues who were steeped in C++ had a good laugh at my expense because I was building server-side web applications with a new framework and a hot, new language. It woefully under-performed similar C++ applications in benchmark tests.

It was 1998, and the language was Java. I could write my applications much faster and in a more maintainable way than they could, but they didn't care. Their technology was proven, and Java was simply a fad.

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

#100

Post by zafriedman »

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