Hacker News Reader

Comment by IsaacSchlueter | Hacker News Reader

That's not really a valid test. NodeJS can easily make use of multiple cores with child processes, but by design, it's a very low-level API, so that stuff isn't used by the HTTP server by default. In other words, it doesn't assume you want to use multiple processes for your HTTP server. Maybe you want to use them for something else. (Like, if you have an HTTP server and an IRC server sharing the same box, and you want to make sure they are isolated from one another, or something.)

Check out http://github.com/kriszyp/multi-node or http://github.com/extjs/Connect for examples of web servers that will blow Clojure out of the water in this benchmark.

When leveraging multiple cores, NodeJS is closer to nginx in terms of performance than it is to Jetty or Django. (Of course, nginx uses almost no memory, and NodeJS has this big honkin VM juggling JavaScript contexts, so it's not as space-efficient.)

View on HN

For stupid web apps that serve content straight from cache, or for servers that are very I/O bound (like anything involving messaging) ... then Node.js may blow Clojure out of the water.

For everything else ... i.e. most startups I see on HN ... you really have to take the CPU-bound or synchronous logic out of Node.js, otherwise it sucks big donkey balls.

People striving for the ultimate development experience have really forgotten what it's like to have brute processing power. Web apps like PlentyOfFish which had 1.2 billion page views/month in 2009 ran only on 2 balanced web servers ... and this considering that on a dating site everything's dynamic, you really can't have too much caching.

Clojure might turn out to be the best of both worlds ... a productive programming language coupled with the brute CPU-bound performance that the JVM can yield.

Strangely enough this post has caused me to decide to give D another wag.

At first I misread what you said as "NodeJS can easily make use of multiple cores with child processes, by design". It's true, though. Many NodeJS proponents know this. Google Chrome, which uses the same JavaScript engine, V8, works the same way. The fact that it uses lots of lightweight processes is a big selling point of Chrome.

I'm not completely sure about this, but I remember hearing that SpiderMonkey is more suited to using threads, and that's why CouchDB uses it rather than V8.

Multiple processes are an inefficient way of making use of multiple cores. Either you pay memory overhead to duplicate state, or you pay IPC overhead to get access to shared state of some kind.

In many cases it's more efficient precisely for the reasons you mention. Data duplication removes locking and cache coherence penalties. If you structure your program to communicate by message passing over IPC (for example, via a database) you get those benefits, plus possibly more efficient mutual exclusion mechanisms (CAS, tuned MVCC, etc).

Also, don't forget that GC penalties are going to be paid by all threads in a process.

Multiple threads in a single process doesn't preclude data duplication in any way; and optimal IPC is always going to be slower than optimal in-process message passing. I wouldn't consider bringing a database into the communication channel to ever approach optimality.

As to GC, that presumes that you are using GC. For a request/response style server application, there are more optimal techniques than GC: make sure all request-associated allocations come out of a per-request heap, and you can free that heap en masse, in one go, once that request is done with.

assuming you proxy requests to the different processes. that's not what those examples are doing - they simply share a server socket and let the kernel load balance incoming connections over them.

Reply on news.ycombinator.com