Clojure's edge on Node.js

http://dosync.posterous.com/22397098

by swannodette • 16 years ago

113 65 16 years ago

dosync.posterous.com

kouPhax3• 16 years ago

Not a massive fan of clojures syntax though - that example is like bracket city!

stanleydrew• 16 years ago

People say similar things about javascript.

twism• 16 years ago

Counted the same number of brackets in both Node.JS and Clojure examples.

kouPhax3• 16 years ago

That may be but it doesn't stop the clojure code looking messy IMHO. Feels less structured (again IMHO)

francoisdevlin• 16 years ago

It's not bracket city, those are all Clojure data structures. The example could also be written like this:

http://gist.github.com/468107

Code is data :)

compay3• 16 years ago

Syntax aesthetics shouldn't be an important metric for technology choices.

kouPhax3• 16 years ago

They "shouldn't" be, but more often than not they are. At least in my experience of try to introduce people to new languages/technologies.

Calamitous• 16 years ago

Why not? Aesthetics improve readability and maintainability, (probably) trading out for less raw speed. If I'm less concerned about performance than maintainability, why shouldn't aesthetics play a large role in my decision?

InclinedPlane• 16 years ago

Counter-point: http://en.wikipedia.org/wiki/Brainfuck

cageface2• 16 years ago

Threads aren't going to scale to the same number of concurrent clients as an evented system though. Isn't that the whole point of things like node? Serving huge numbers of relatively lightweight requests?

nullstyle2• 16 years ago

http://www.jboss.org/netty/performance/20090607-asalihefendi...

At the very least some hackers out there are able to make it scale quite well. Does anyone have a comparable anecdote for Node.js (honest question)?

shorrockin• 16 years ago

plurk themselves recently moved away from netty and towards node. While you could argue this was a bad choice, it is an interesting footnote:

http://amix.dk/blog/post/19490#Plurk-Instant-conversations-u...

babo• 16 years ago

This IS an evented system.

cageface2• 16 years ago

I was referring to the second example, using threads. Specifically this claim:

In Clojure we don't need to use callbacks. This means for common things like talking to databases, we don't need them to have asynchronous interfaces. That's because we have really fantastic primitives in the language itself for dealing with concurrency. This code runs twice as fast as the Node.js counterpart - probably due to the excellent perf of Clojure coupled with leveraging multiple cores.

donw2• 16 years ago

If you're doing thread-per-request, than no. If you've got an event-driven I/O system backed by a thread pool for executing parallel requests, than yes.

I set up a Rack adapter through Jetty 7 on JRuby that works exactly like this. The SelectChannelConnector is event-driven I/O, and the QueuedThreadPool handles requests in parallel.

The result? 6k req/sec on my laptop for a simple Rack app, basically the same as what's shown in these examples, since my machine is quite a bit slower, and I've clocked 10k/sec on faster machines.

(By the way, if you're interested, the Rack handler is in a gem called 'mizuno', and is at http://github.com/matadon/mizuno)

gizmomagico• 16 years ago

If you're doing thread-per-request, than no.

Pro-tip: This time, you were looking for the word "then". But "than" really exists too, and is even used sometimes (when comparing things)!

Yeah, downvote away.

jherdman• 16 years ago

That's pretty neat. I've been meaning to learn about Clojure. This is just the thing I needed to encourage me to get off my duff.

ericb2• 16 years ago

I'm not familiar with node.js. What engine is used to run the stand-alone JS? Is it inevitable that is it limited to a single core?

ionfish2• 16 years ago

Node uses Google's V8 virtual machine, which they built for Chrome. JavaScript is single-threaded, so yes, unless you spawn a child process it'll be limited to a single core.

ericb2• 16 years ago

Is being single-threaded part of the JavaScript spec?

srveit2• 16 years ago

It uses Google's open source V8 JavaScript engine. (http://code.google.com/p/v8/) It doesn't support multiple cores AFAIK. To use multiple cores, the server would need to spawn subprocesses or run multiple servers behind nginx.

sjs• 16 years ago

This looks really nice! Our server is based on Node right now but we've had the idea of porting to Erlang later. Maybe Clojure + Netty is another option to explore.

IsaacSchlueter• 16 years ago

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

barrkel5• 16 years ago

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.

ppplll• 16 years ago

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.

sedachv5• 16 years ago

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.

bad_user• 16 years ago

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.

Goosey• 16 years ago

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

benatkin• 16 years ago

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.

felixge5• 16 years ago

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?

swannodette• 16 years ago

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?

felixge5• 16 years ago

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.

mhd3• 16 years ago

The main problem both systems have is that they're relatively immature. node.js is still undergoing heavy development, with a few breaking changes every couple of releases (although it's slowing down in that regard). And aleph basically just came out, right?

So I'd regard both as "things to watch" or bootstrapping solutions, not something I'd use for my Global Thermonuclear War management system.

stratospark• 16 years ago

But they're already using node to manage Global Thermonuclear War: http://wargamez.mape.me/

Periodic2• 16 years ago

I agree. I had a similar problem with CouchDB a while ago when I tried to write the application in CouchDB. The interface was there, but it was obvious that some of the key features hadn't been implemented yet, requiring painful and complex workarounds. I went back to technologies I knew were tried and true.

If you're interested in playing around with tech and having fun, then these technologies are great. But for business I would avoid them for now.

I'm hoping they gain some traction though.

prospero• 16 years ago

I wrote Aleph this weekend, so yes, it's very new. However, right now it's just a few hundred lines around Netty, which is anything but immature.

I'm certainly not claiming it's flawless, or that there won't be any breaking changes in the future. However, I think this is a great example of one of Clojure's strengths: even brand new projects tend to have solid, well-tested foundations.

mhd3• 16 years ago

Well, the same could be said about node.js and libev, to be honest.

j_baker• 16 years ago

Of course if that's what you're looking for, twisted[1] is the only way to go.

[1] http://twistedmatrix.com/trac/

mhd3• 16 years ago

For event-based frameworks, if I'm generally in the market for reliable concurrency, Erlang would probably be a prime candidate, too.

Periodic2• 16 years ago

I initially had Javascript off, so I figured it was part of the joke when the space for the shortest Node.js web server was empty. When the shortest Clojure web server was also zero characters, I got suspicious.

Don't forget to add a non-Javascript version for people without Javascript (rare) and bots (common).

c00p3r• 16 years ago

btw, did anyone have a look at node's sources? It is terrible mess.

Actually, using something like nginx-pr (a-la apache's apr) would be much better solution than this bunch of hacks.

But people never listen. ^_^

Clojure's edge on Node.js

Related Stories