75

I'm not very experienced in web programming, and I haven't actually coded anything in Node.js yet, just curious about the 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 :)

Community
  • 1
  • 1
Hendry Ten
  • 1,072
  • 1
  • 10
  • 11

4 Answers4

68

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

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

http://blip.tv/file/2899135

http://nodeguide.com/

kmonsoor
  • 7,600
  • 7
  • 41
  • 55
Raynos
  • 166,823
  • 56
  • 351
  • 396
  • 2
    ASP.NET is not designed to be event-driven. But what is so special about event-driven itself? – Hendry Ten Apr 08 '11 at 18:32
  • 17
    ASP.NET doesn't create thread on every requests, that's what thread pool is for. – Hendry Ten Apr 08 '11 at 18:33
  • 8
    Every IO action, even the aspx page, can be async if needed. – Hendry Ten Apr 08 '11 at 18:35
  • 5
    @HendryTen but if you have 100 clients connection right _now_ in parallel then there would be a 100 threads or at least n threads and 100 - n clients waiting in a buffer. Asynchronous IO is the right way to do it. One of the ways to do asychronous IO is to be event driven. Watch this [video](http://blip.tv/file/2899135) – Raynos Apr 08 '11 at 18:36
  • 4
    @Raynos, and in node.js those will be in queue? There shouldn't be necessarily 100 threads. That was the proper async usage of the thread for. Only several threads wait for requests, more others for work/call async or handle callback etc. – Hendry Ten Apr 08 '11 at 18:42
  • @HendryTen if every one of your 100 clients call the database synchronously then a lot of them will be waiting. Yes you can do it in a similar fashion but your fighting againts the ASP.NET technology to do it a way like node.js. Also you can't argue againts the memory stamp. node.js's memory stamp for n requests is low compared to IIS. – Raynos Apr 08 '11 at 18:46
  • @Raynos, agree on the memory stamp. For the 100 calls to the database, all of them should be handled async-ly using callback (can this be done? dunno hehe). You can't say that it's fighting the ASP.NET technology. What to say about ASP.NET MVC then? – Hendry Ten Apr 08 '11 at 18:50
  • @HendryTen ASP.NET MVC has asynchronous db access? All tutorials I've read all show you how to access the database synchronously through Entities. You have to see that an average .NET developer will do synchronous calls. Your entire beautiful asynchronous .NET web technology will collapse with a single synchronous call. As @AaronMaenpaa says it's a culture difference. In node.js I can easily do 10k aysnchronous database calls at the same time. If each call takes 2s all 10 thousand will take about 2.02s. – Raynos Apr 08 '11 at 18:55
  • @Reynos: Sorry that's two points on one comment. ASP.NET MVC don't have anything to do with the database. It just for replying your comment about fighting the ASP.NET tech, while MVC did the same to the base ASP.NET technology. – Hendry Ten Apr 08 '11 at 18:59
  • @HendryTen I was making a comparison between ASP.NET & node.js.ASP.NET MVC is different. My code ASP.NET MVC code still calls an Action in a Controller synchronously which returns a View synchronously. I don't know whether ASP.NET MVC has anything asynchronous under the hood but I don't see any of it myself. I prefer node due to the lack of abstraction and the control. Besides I'd go for node because I don't have to pay licence fees to microsoft. – Raynos Apr 08 '11 at 19:01
  • @Reynos: Accessing the database using Entities is just a easier/lazier/more managable way. If one walk down the path of the asp.net async, they should be prepared to do all the async stuff, including database access. While I don't really know how to do that async-ly, I'm sure it is plausible. – Hendry Ten Apr 08 '11 at 19:02
  • @HendryTen of course its plausible. But you must be able to see that doing this in node is easier and feels less like an uphill struggle. node.js was made from the ground up to do this. I spend 15 minutes making the server-side views & models available to the client and with 15 lines of code I had the clients render server side views & models on the client over ajax. It's feels natural, it's fleunt, but it's hard. – Raynos Apr 08 '11 at 19:04
  • @Raynos: There is Async action controller/invoker (forget what the class is) in MVC. And you don't really need to pay license to Microsoft for using IIS. – Hendry Ten Apr 08 '11 at 19:06
  • @Raynos: Sure it is easier (but, at least now, can you beat the .NET lib??), but that's not what's the point. I'm finding a reason so big that makes me want to move from the current comfort zone. So this really have been "what can't I do? Why should I change?" arguments. – Hendry Ten Apr 08 '11 at 19:09
  • @HendryTen you still have to pay for SQL Server and MS Server 2008 – Raynos Apr 08 '11 at 19:10
  • 1
    @HendryTen I just don't have enough hand on experience writing anything that isn't a tech demo in node.js. I'll be doing some proper development in it and writing websites in it give me a week or 2 and I'll have a proper blog series up showing what it's like to develop with node.js. I'll recommend this [video again](http://blip.tv/file/2899135). It's the reason I'm excited about it. – Raynos Apr 08 '11 at 19:12
  • @Reynos, sure. Please do send me updates on this. I'm very interested and actually fighting my heart to not do node.js. – Hendry Ten Apr 08 '11 at 19:17
  • @Raynos, +1 for the effort. We might not agree on this, but your answer is better :) – Frédéric Hamidi Apr 08 '11 at 19:21
  • @HendryTen I have a temporary blog set up [here](http://gamewithnodejs.blogspot.com/). And I'll be opening a new one once I've finished writing my blog site in node. Also I would like to recommend taking a look at [now.js](http://nowjs.com/). That's some really powerful stuff and is made "easy" because of node. Of course at the node.js HTTP server vs IIS level, node has a giant advantage, just like any "apache vs nginx" discussion, at the node.js vs ASP.NET level it's less obvouis. – Raynos Apr 08 '11 at 19:21
  • 1
    On the topic of performance between the two, I found this interesting. Scott claims he can get "22,500 requests a second" with an IHTTPHandler on ASP vs 10,000 a second with Node (on IIS). http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx – Damien Sawyer Feb 06 '12 at 23:56
  • Nodejs vs IIS perf comparison for dishing out STATIC HTML on WINDOWS. IIS is about 2.5 times faster than Nodejs. But surprise, Tomcat is about 3 times faster than IIS. See my other answer at so: http://stackoverflow.com/questions/9290160/node-js-vs-net-performance/10641377#10641377 – Shankar May 18 '12 at 18:31
  • 12
    _"Threads are just hard."_ LOL. _"Performance. It's fast. Real fast."_ LOL _"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."_ LOL. There sure is some quality humour in this answer :) – kralyk Feb 22 '17 at 08:38
28

There are a lot of misconceptions regarding node.js vs. ASP.Net and asynchronous programming. You can do non blocking IO in ASP.NET. Most people don't know that the .Net framework uses Windows iocompletion ports underneath when you do web service calls or other I/O bound operations using the begin/end pattern in .Net 2.0 and above. IO completion ports is the way the Windows operating system supports non-blocking IO so that the app thread is freed why the IO operation completes. Interestingly, node.js uses a less optimal non blocking IO implementation in Windows through Cygwin. A new Windows version is on the road map, which with Microsoft's guidance will be using IO completions ports. At that point there is underneath no difference.

It is also possible to do non-blocking database calls in ADO.NET but be aware of ORM tools such as NHibernate and Entity Framework. They are still very much synchronous.

Synchronous IO (blocking) makes the control flow much clearer and it has for this reason become popular. The reason why computer environments are multithreaded has only superficially to do with this. It is more generally related to time sharing and utilization of multiple CPUs.

Having only a single thread can cause starvation during lengthy operations, which can be related to both IO and complex computations. So, even though the rule of thumb is one thread pr. core when utilizing non-blocking IO, one should still consider a sufficient thread pool size so that simple requests don't get starved by more complex operations if such exist. Multiple threads also allows complex operations to be split easily among multiple CPUs. A single threaded environment like node.js can only utilize multicore processors through more processes and message passing to coordinate action.

I have personally not yet seen any compelling argument to introduce an additional technology such a node.js. However, there may be good reasons but they have in my opinion little to do with servicing a large number of connections through non-blocking IO since this can also be done with ASP.NET.

BTW tamejs can help make your nodejs code more readable similar to the new upcoming .Net Async CTP.

Codefather
  • 281
  • 3
  • 3
  • Yeah, I don't think the Node community does itself any favors by claiming drastic performance improvements. Enabling smaller teams to develop rapidly without sacrificing perf or limiting your options is it's true strength. + Yay! if you like JavaScript. – Erik Reppen Jun 11 '13 at 18:03
17

It is easy to understate the cultural difference between the Node.js and ASP.NET communities. Sure, IHttpAsyncHandler exists and it's been around since .NET 1.0 so it might even be good, but all of the code and discussion around Node.js is about async I/O which is decidedly not the case when it comes to .NET. Want to use LINQ To SQL? You kind of can, kind of. Want to log stuff? Maybe "CSharp DotNet Logger" will work, maybe.

So yes, IHttpAsyncHandler is there and if you're really careful you might be able to write an event driven web-service without tripping over some blocking I/O somewhere, but I don't really get the impression a lot of people are using it (and it certainly isn't the prominent way for writing ASP.NET apps). In contrast, Node.js is all about evented I/O, all the code examples, all the libraries and it's the only way people are using it. So if you were going to bet on which one's evented I/O model actually worked all the way through, Node.js would probably be the one to pick.

Community
  • 1
  • 1
Aaron Maenpaa
  • 119,832
  • 11
  • 95
  • 108
  • 2
    I think you're taking Async IO too seriously. It's cool, it sometimes makes things faster. it always makes things more complicated. I think you should take a closer look at .Net 4.5 ... – AK_ Apr 14 '13 at 08:11
  • @AK_ but both async and event-driven are second nature to JS devs with a ton of UI experience. The biggest difference in cultures, IMO, is a preference for minimalism over feature-list length both in language, implementation, and typical library/tool design. That preference comes from years of writing code for multiple platforms that don't all necessarily agree on what your code actually means and I think it will continue to serve experienced JS devs well in Node. Async with JS's malleability and its flavor of first-class functions means a lot less code in the hands of a strong JS dev. – Erik Reppen Jun 11 '13 at 18:41
2

As per current age technology improvements and reading below links, I can say, it is matter of expertise and choosing perfect mix as per the particular scenario that matters. NodeJS is getting mature and ASP.NET side we have ASP.NET MVC, WebAPI, and SignalR etc. to make things better.

Node.js vs .Net performance

http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ and

http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx

Thanks.

Community
  • 1
  • 1
Praveen Prajapati
  • 969
  • 1
  • 16
  • 21