Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Node's requests/second scale linearly with the amount of processes used. Here is an example for doing that:

http://gist.github.com/430932

So node would probably outperform the given clojure example by 13.5K req/s vs. 8.5k req/s (YMMV).

It is also worth noting that clojure library used (aleph), does not seem to support streaming the response.

The most interesting aspect is clojure's support for futures, and Javascripts lack of such. If you're willing to trade speed for cheap syntactical pleasure, clojure has an advantage here : ).

edit: Who down voted this / why?



Clojure should also scale very well on a real 4 core machine (it's the JVM after all). And I wouldn't be surprised if was neck-to-neck with Node.js. Without numbers it's just talk (I don't have access to a real four core machine so I can't say myself).

Also I note that your code is very verbose for managing multiple cores while the Clojure version is pretty much identical to the original Node version.

So much for cheap syntactical pleasures, eh?


The clojure example is using a library. There are libraries for node that make the process handling just as easy.

Anyway, I think you are mistaken if you believe a clojure http server could outperform it's node counterpart. I mean node is really just a set of air-thin Javascript bindings to some pretty good C code / native system calls. Node's http parser is also written in C.


The problem with benchmarking raw node.js code is that not a lot of real web apps will look like that. Naked node.js pushes all the asynchronous complexity on the application writer - writing everything with callbacks is equivalent to hand-writing a state machine.

Since V8 does not have native continuation support, realistically it's going to devolve to libraries either doing CPS transformation (http://gfxmonk.net/2010/07/04/defer-taming-asynchronous-java...) or monads (http://matthew.yumptious.com/2009/04/javascript/dojo-deferre...), which both involve performance penalties.

A fair comparison on say a 4-core machine would be 4 JVMs running Clojure webservers with some front-end, and 4 node.js instances running one of the library front-ends, with the benchmarked page written with one of the CPS-transforming toolkits (coffeescript, narrative JS, jwacs, etc.) or maybe monad toolkits if/when somebody decides to write one.


Claims are pointless without backing benchmarks. Being written in C is no guarantor of performance.


http://developer.yahoo.com/yui/theater/video.php?v=dahl-node

Shows node to outperform nginx for serving a static 1 MB buffer.


What does that have to do with performance under multiple processors / cores?


Node's scales linearly if you add a process per additional core (see my original link). That does allow for a certain extrapolation from a single process/cpu benchmark.

Anyway, you are correct - a real benchmark between node / clojure would be needed to proof my argument. But I think reasoning about the underlaying machinery is a better use of my time in this case. Bugs aside, there is no reason to believe Clojure could perform faster if it ends up doing more work under the hood. And from what I can tell, there are many more layers of abstraction in between clojure's http implementation and the native system calls, than there are for node.


This is unrelated to the OP, but the node.js HTTP parser is extremely cool:

http://four.livejournal.com/1033160.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: