multithreading - What so different about Node.js's event-driven? Can't we do that in ASP.Net's HttpAsyncHandler?

itemprop="text">

I'm not very experienced in web
programming,
and I haven't actually coded anything in Node.js yet, just
curious about the href="http://code.danyork.com/2011/01/25/node-js-doctors-offices-and-fast-food-restaurants-understanding-event-driven-programming/">event-driven
approach. It does seems good.

The
article explains some bad things that could happen when we use a thread-based approach
to handle requests, and should opt for a event-driven approach instead.
In
thread-based, the cashier/thread is stuck with us until our food/resource is ready.
While in event-driven, the cashier send us somewhere out of the request queue so we
don't block other requests while waiting for our food.
To scale the blocking
thread-based, you need to increase the number of threads.
To me this seems
like a bad excuse for not using threads/threadpools
properly.

Couldn't that be properly
handled using IHttpAsyncHandler?
ASP.Net receives a request, uses the
ThreadPool and runs the handler (BeginProcessRequest), and then inside it we load the
file/database with a callback. That Thread should then be free to handle other requests.
Once the file-reading is done, the ThreadPool is called into action again and executes
the remaining response.
Not so different for me, so why is that not as
scalable?

One of the disadvantages of the
thread-based that I do know is, using threads needs more memory. But only with these,
you can enjoy the benefits of multiple cores. I doubt Node.js is not using any
threads/cores at all.

So, based on just the
event-driven vs thread-based (don't bring the "because it's Javascript and every
browser..." argument), can someone point me out what is the actual benefit of using
Node.js instead of the existing technology?

That
was a long question. Thanks :)

class="post-text" itemprop="text">

class="normal">Answer

First of
all, Node.js is not multi-threaded. This is important. You have to be a very talented
programmer to design programs that work perfectly in a threaded environment. Threads are
just hard.

You have to be a
god to maintain a threaded project where it wasn't designed
properly. There are just so many problems that can be hard to avoid in very large
projects.

Secondly, the whole platform was
designed to be run asynchronously. Have you see any ASP.NET project where every single
IO interaction was asynchronous? simply put, ASP.NET was not designed to be
event-driven.

Then, there's the memory footprint
due to the fact that we have one thread per open-connection and the whole scaling issue.
Correct me if I'm wrong but I don't know how you would avoid creating a new thread for
each connection in ASP.NET.

Another issue is
that a Node.js request is idle when it's not being used or when it's waiting for IO. On
the other hand, a C# thread sleeps. Now, there is a limit to the number of these threads
that can sleep. In Node.js, you can easily handle 10k clients at the same time in
parallel on one development machine. You try handling 10k threads in parallel on one
development machine.

JavaScript
itself as a language makes asynchronous coding easier. If you're still in C# 2.0, then
the asynchronous syntax is a real pain. A lot of developers will simply get confused if
you're defining Action<> and
Function<> all over the place and using callbacks. An
ASP.NET project written in an evented way is just not maintainable by an average ASP.NET
developer.

As for threads and cores. Node.js is
single-threaded and scales by creating multiple-node processes. If you have a 16 core
then you run 16 instances of your node.js server and have a single Node.js load balancer
in front of it. (Maybe a nginx load balancer if you
want).

This was all written into the platform at
a very low-level right from the beginning. This was not some functionality bolted on
later down the line.

Other
advantages

Node.js has a lot more
to it then above. Above is only why Node.js' way of handling the event loop is better
than doing it with asynchronous capabilities in
ASP.NET.

• Performance.
  It's fast. Real fast.


• One big advantage of Node.js is its
  low-level API. You have a lot of control.


• You have the
  entire HTTP server integrated directly into your code then outsourced to
  IIS.


• You have the entire nginx vs Apache comparison.
  


• The entire C10K challenge is handled well by node but
  not by IIS


• AJAX and JSON communication feels natural and
  easy.


• Real-time communication is one of the great things
  about Node.js. It was made for it.


• Plays nicely with
  document-based nosql databases.



• Can run a TCP
  server as well. Can do file-writing access, can run any unix console command on the
  server.


• You query your database in javascript using, for
  example, CouchDB and map/reduce. You write your client in JavaScript. There are no
  context switches whilst developing on your web
  stack.


• Rich set of community-driven open-source modules.
  Everything in node.js is open source.


• Small footprint and
  almost no dependencies. You can build the node.js source
  yourself.

Disadvantages
of Node.js

It's hard. It's young.
As a skilled JavaScript developer, I face difficulty writing a
website with Node.js just because of its low-level nature and the level of control I
have. It feels just like C. A lot of flexibility and power either to be used for me or
to hang me.

The API is not frozen.
It's changing rapidly. I can imagine having to rewrite a large website completely in 5
years because of the amount Node.js will be changed by then. It is do-able, you just
have to be aware that maintenance on node.js websites is not
cheap.

further
reading

href="http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/"
rel="nofollow
noreferrer">http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

href="http://blip.tv/file/2899135" rel="nofollow
noreferrer">http://blip.tv/file/2899135

href="http://nodeguide.com/" rel="nofollow
noreferrer">http://nodeguide.com/