Clojure's edge on Node.js

Re:Clojure's edge on Node.js by IsaacSchlueter on Thursday July 08, 2010 @12:43PM (#1497890)

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

[ Parent | on HN ]

Re:Clojure's edge on Node.js by bad_user on Thursday July 08, 2010 @02:23PM (#1498273)

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.

[ Parent | on HN ]

Re:Clojure's edge on Node.js by Goosey on Friday July 09, 2010 @12:34AM (#1499785)

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

[ Parent | on HN ]

Re:Clojure's edge on Node.js by benatkin on Thursday July 08, 2010 @07:20PM (#1499123)

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.

[ Parent | on HN ]

Re:Clojure's edge on Node.js by barrkel on Thursday July 08, 2010 @12:47PM (#1497909)

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.

[ Parent | on HN ]

Re:Clojure's edge on Node.js by sedachv on Thursday July 08, 2010 @04:12PM (#1498605)

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.

[ Parent | on HN ]

Re:Clojure's edge on Node.js by barrkel on Thursday July 08, 2010 @04:20PM (#1498635)

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.

[ Parent | on HN ]

Re:Clojure's edge on Node.js by ppplll on Thursday July 08, 2010 @12:51PM (#1497919)

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.

[ Parent | on HN ]