Nodejs for Concurrency

[Juan]

I've been recently looking at some of the existing solutions for
concurrent http servers, among them: Scala with akka (Actor based) and
Python circuits (modular event based) library. It seems that Node.js
would be good for the job. What would be the advantages of Node.js
over both previous mentioned solutions?

[Bluebie]

Well, I know not of Scala and Akka, but I presume Python's circuits
would work somewhat like Ruby's event machine, being an extension one
loads in to regular python, rather than an entirely new interpreter
breaking backwards compatibility with existing APIs.

The trouble with libraries like EventMachine, is that while the
libraries and what they provide are very good, all the other junk in
the language is generally built around synchronous APIs, so server
authors need to be extremely conscious of that, and in many cases
simply cannot use existing libraries. Worse yet, sometimes there is
synchronous file IO where coders aren't expecting it to be happening,
making performance issues difficult to debug.

Node's main feature above pre-existant systems is that it provides a
rich set of Async APIs in a language which was designed from the start
to work in an event loop, and which is already very familiar to a
large number of developers. You don't need to specifically avoid
anything in Node, or really understand event loops or the difference
between synchronous and asynchronous APIs, or at least, that was the
dream, until CommonJS muddied those waters. The web is asynchronous.
Client side web programmers are very used to dealing with that fact.

In more general terms however, the advantage is that javascript is an
awesome, simple, powerful, and extremely fast language, with an
absolutely huge and well commercially funded community invested in to
making it even faster. It is in wide use, with a huge array of
existing code easy to drop in and use, is easy for beginners to learn,
and when using it on the server side as well as in browser-based
clients, you avoid having to switch your mind between two different
languages when developing your application and moving between client
and server. There are also some advantages to being able to share
source code between your client and server, in being able to do
validation, share compression or encryption routines, etc. With
browsers now providing SQL and Key/Value databases, and Node now
providing llbxml access, the similarities are growing immensely.

Node isn't necessarily the best tool for a particular unknown job.
Just use what you like. I like javascript. You can certainly get
similar performance from those other tools though too. :)

[francisco treacy]

Don't know how much I can add to what Bluebie said :)

Personally I started working on this app where frontend was heavily
relying on javascript, the backend was written in Scala (so a step
further would've been Akka) and Riak as a database.

As the Scala layer was quite thin (at least for the moment) I was
basically parsing json into Scala data structures, make some slight
manipulations, convert back into json and sent to the db - or
viceversa. Quite verbose, even if the Scala json library I use is
really neat. In this case the statically-typed language kept on
getting in my way.

When I found node it all suddenly just made sense. It's event based
(which matches javascript perfectly well) and super fast. But more
importantly, I am only dealing with one language across all layers
with no "mismatch". Even though you do have to parse and stringify
json, it all feels more natural.

I still process queue jobs with infrastructure built on Scala (parsing
xml, and so on - it's neat and makes sense) but for the server, and so
far, node in my case feels like the perfect fit.

Francisco

2009/12/18 Bluebie <bl...@creativepony.com>:

> --
>
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>
>

[Karl Guertin]

On Thu, Dec 17, 2009 at 10:27 PM, Juan <juan...@yahoo.com> wrote:
> I've been recently looking at some of the existing solutions for
> concurrent http servers

You need to be aware that node.js is not at all concurrent. It's a
single threaded event loop so if you're doing heavy processing in that
loop, you're going to bog down. The strategy for dealing with this is
to fire off async requests to do the heavy processing (e.g. database
lookup) elsewhere and use the loop only for dispatch. This pattern
works very well for most network servers. Ryan has mentioned that he'd
like to add something like workers to node (fire off a long running
calculation on a thread, get a callback when it's done) but they're
not there yet so you have to do your processing in another process.
The advantage of having everything single threaded makes it extremely
easy to reason about the program.

If you're looking for a real concurrency solution, my favorite is
Clojure which uses immutable (more correctly persistent) data
structures, functional programming, and MVCC STM to make things work.
Erlang/OTP also works well using a combo of functional programming and
green threads but I hate the syntax. A lot of other languages have
tried to adapt actors from Erlang but I'm not sure how well they work
without OTP and the Erlang VM. Note that I'm just a programmer who's
been searching for a concurrency solution for a few years, not an
academic, so I could have something wrong or be overlooking an area
but that's what you get on a mailing list.

--Karl

[Tim Caswell]

Depending on your meaning of the word "concurrent", Node may do what you need. A good analogy that helped my wife understand node's model is that of a doctor's office.

A traditional threaded http server is like a doctor's office that has one main reception window. Upon meeting the receptionist, suddenly a new window to the side appears and you're sent to that one. The new receptionist hands you a paper to fill out and you stay there at the window filling out your paperwork. Meanwhile, other patients come in the office and new windows get created for them. This works well, except you now have many receptionists sitting idle waiting for you to fill out paperwork. This can get very expensive. Also there is the complexity of ensuring that two windows aren't modifying the same record at the same (mutexes in threading).

The single threaded pattern used is node is what most offices really do. They hand you the paperwork and send you to your seat to fill it out. When you're done, you stand in the back of the line (if there is one) and wait to turn your papers back in. This system only requires a single window since the receptionist never site idle waiting for you to fill out paperwork.

So in a way it's concurrent in that a single window can be waiting on multiple people at once, but at the same it's not concurrent because the receptionist at the single window is always only doing one thing at once. The downside of this, like Karl said, is that if you are at the window and the receptionist is busy doing something for you that takes a while, then other people in the line simply have to wait for you to finish. There is no interrupting.

So basically in conclusion. Node can only be actively be doing one thing at a time, but it can be waiting on as many things as needed. This model works great for things like web servers where most time is spent in IO wait or some other kind of wait state.

[Karl Guertin]

On Fri, Dec 18, 2009 at 11:46 AM, Tim Caswell <t...@creationix.com> wrote:
> Depending on your meaning of the word "concurrent", Node may do what you need.  A good analogy that helped my wife understand node's model is that of a doctor's office.

Yeah, I should probably say threaded instead of concurrent here. It's
just that most of the discussion about "concurrent programming" skips
over os-process concurrency so I tend to make that jump when it comes
up in discussion. In my defense, the projects he does mention are
thread level concurrency.

[Tim Caswell]

Don't worry, I usually prefer to make concurrent mean doing more than one thing actively at once. This is something node doesn't do. (At least not in the main event loop).