4

We are planning to start a fairly complex web-portal which is expected to attract good local traffic and I've been told by my boss to consider/analyse node.js for the serve side. I think scalability and multi-core support can be handled with an Nginx or Cherokee in front.

1) Is this node.js ready for some serious/big business?

2) Does this 'event/asynchronous' paradigm on server side has the potential to support the heavy traffic and data operation ? considering the fact that 'everything' is being processed in a single thread and all the live connections would be lost if it got crashed (though its easy to restart).

3) What are the advantages of event based programming compared to thread based style ? or vice-versa. (I know of higher cost associated with thread switching but hardware can be squeezed with event model.)

Following are interesting but contradicting (to some extent) papers:-

1) http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html

2) http://pdos.csail.mit.edu/~rtm/papers/dabek:event.pdf

3 Answers3

4

  1. Node.js is developing extremely rapidly, and most of its functionality is sturdy and ready for business. However, there are a lot of places where its lacking, like database drivers, jquery and DOM, multiple http headers, etc. There are plenty of modules coming up tackling every aspect, but for a production environment you'll have to be careful to pick ones that are stable.

  2. Its actually much MUCH more efficient using a single thread than a thousand (or even fifty) from an operating system perspective, and benchmarks I've read (sorry, don't have them on hand -- will try to find them and link them later) show that it's able to support heavy traffic -- not sure about file-system access though.

  3. Event based programming is:

    1. Cleaner-looking code than threaded code (in JavaScript, that is)

    2. The JavaScript engine is extremely efficient with processing events and handling callbacks, and its easily one of the languages seeing the most runtime optimization right now.

    3. Harder to fit when you are thinking in terms of control flow. With events, you can never be sure of the flow. However, you can also come to think of it as more dynamic programming. You can treat each event being fired as independent.

    4. It forces you to be more security-conscious when programming, for the above reason. In that sense, its better than linear systems, where sometimes you take sanitized input for granted.

As for the two papers, both are relatively old. The first benchmarks against this, which as you can see, has a more recent note about these studies:

http://www.eecs.harvard.edu/~mdw/proj/seda/

It also cites the second paper you linked about what they have done, but refuses to comment on its relevance to the comparison between event-based systems and thread-based ones :)

Vanwaril
  • 7,380
  • 6
  • 33
  • 47
0

See What is Node.js? where we cover exactly that:

Node in production is definitely possible, but far from the "turn-key" deployment seemingly promised by the docs. With Node v0.6.x, "cluster" has been integrated into the platform, providing one of the essential building blocks, but my "production.js" script is still ~150 lines of logic to handle stuff like creating the log directory, recycling dead workers, etc. For a "serious" production service, you also need to be prepared to throttle incoming connections and do all the stuff that Apache does for PHP. To be fair, Rails has this exact problem. It is solved via two complementary mechanisms: 1) Putting Rails/Node behind a dedicated webserver (written in C and tested to hell and back) like Nginx (or Apache / Lighttd). The webserver can efficiently serve static content, access logging, rewrite URLs, terminate SSL, enforce access rules, and manage multiple sub-services. For requests that hit the actual node service, the webserver proxies the request through. 2) Using a framework like "Unicorn" that will manage the worker processes, recycle them periodically, etc. I've yet to find a Node serving framework that seems fully baked; it may exist, but I haven't found it yet and still use ~150 lines in my hand-rolled "production.js".

Community
  • 1
  • 1
Dave Dopson
  • 41,600
  • 19
  • 95
  • 85
0

Try yourself to discover the truth

jmarranz
  • 6,459
  • 2
  • 21
  • 10