2

I am trying to learn Node.js and some of points that I understand:

  1. Node.js does'nt create a seperate process for each request, instead it is just one process which processes all requests.

  2. It is asynchronous which means you can attach a callback to a long-lasting process and continue your rest of the work without waiting for it to finish.

What I really don't understand is author's point in Understanding node.js - "Everything runs in parallel except your code". I have understood the analogy and the code that explains it but still I don't get it what is the distinction between "Everything" and "code". I have more often heard this about node.js.

Also, people pat node.js for its efficiency since memory overhead for one concurrent connection may be as low as 8KB but what about CPU load. Does node.js make it way less as compared to PHP+Apache?

Shubham
  • 21,300
  • 18
  • 66
  • 89
  • I think it might be helpful to you if you understand that HTTP doesn't have to have anything to do with your Node.js application. Node applications are nothing but JavaScript running in V8. They don't have to have anything to do with the web at all! It is commonly used for HTTP requests, but it doesn't have to have anything to do with it. – Brad Jul 15 '12 at 17:35

4 Answers4

5

Node.js uses a single thread any time it is running the JavaScript in your application. Tasks that are asynchronous (network, filesystem, etc.) are all handled on separate threads automatically for you. This means that you get much of the usefulness of a multithreaded application without having to worry about all of the trouble that comes with locking resources and what not.

Node is not a tool for every job. It is ideal for applications that are IO bound. For example, if your application required a ton of work to process templates and what not, Node probably isn't for you. If instead you're just shuffling data around, Node can be very effective.

The reason Node is often quoted as being faster than servers like Apache is that it doesn't create a thread and all of the resources with it to handling requests. In Apache, most of the time, that thread handling requests is waiting on network or filesystem data. While it does this, it is wasting resources. With Node, only one thread processes those requests (in your application). Again, this is great for some things, but if you have a lot of processing to do, Node would not be effective as it can really only handle a single request at a time in these situations.

This video does a pretty good job of explaining: http://www.youtube.com/watch?v=F6k8lTrAE2g&feature=youtube_gdata

Brad
  • 159,648
  • 54
  • 349
  • 530
  • So a seperate thread is created for each HTTP request but our JS only runs on one thread, even if it is from different connection – Shubham Jul 15 '12 at 17:32
  • @Shubham, No, separate threads are not created for each HTTP request. However, as you send data back, separate threads are created in the background to handle buffering and what not of that data. – Brad Jul 15 '12 at 17:33
  • Ok a dumb question. What will happen if two requests are send at the same exact time? I mean there is just one process handeling them? (*Confused*) – Shubham Jul 15 '12 at 17:46
  • Your Node.js application is always one process. It is the server... not something started by a server that sits out in front. This is a completely different model than you may be used to from other server-side technologies. If two requests are sent at the same time, they will be handled without problem, provided that the processing of one requests doesn't stall the Node.js process too long. Basically, a request comes in and your code should tell Node "load this file and get back to me", and then process the next request for the same. Node returns the data to your code, and... – Brad Jul 15 '12 at 17:48
  • Your code should then say "Ok Node, send this data you came back with out over the network to requester #1" Node goes off and does that while your code does the same for request #2. etc. – Brad Jul 15 '12 at 17:49
2

Everything runs in parallel except your code.

It means if you do

while(true){}

anywhere in your code the entire node application will stop. While the code you write executes, nothing else does. Requests will not be handled, responses won't be returned, nothing. You have to be extremely careful to not hog the cpu in node.

but what about CPU load?

That completely depends on the nature of your application and the load. If your app is busy, it'll use more cpu.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
2

Imagine a busy intersection with a traffic cop in the middle. When the cop is doing his job properly, hundreds of cars can pass through the intersection in a very fast and efficient way.

If the cop starts receiving and answering SMS messages on his cell while doing traffic, then things might go out of hand really quickly.

The traffic cop is your node.js app, and the time he spends doing SMS is what the author refers to as "your code".

In other words: node.js performance will shine the more you use it as a traffic cop. The more you start using it to do things other than pulling and pushing data (i.e.: sorting a list of numbers, rendering an html template, etc.), the more your capacity to accept and process new connections quickly will suffer.

ziad-saab
  • 19,139
  • 3
  • 36
  • 31
  • So node.js is good if each concurrent request requires lot of work - processing a large database or doing a a very long scraping job? – Shubham Jul 15 '12 at 17:37
  • @Shubham, Your database work should be handled by your database server, so that does not block your application. The HTTP requests for scraping also happen asynchronously, so they do not block your application while that resource is downloaded. Processing the data for your scraping job in your application *does* block until it is done, but you should be writing your code in such a way that it does its work in pieces so blocking isn't a problem. – Brad Jul 15 '12 at 17:52
  • Like the analogy :D @Shubham you have to pass a callback to each call that can be expected to hog the event loop - like accessing the database. This callback contains the part of your application which depends on the data, and is called as the data is available. An ugly consequence of this style of programming is "callback-hell" though. – MauganRa Feb 23 '14 at 14:05
1

"Everything" refers to everything else besides your code. For example, the stuff that handles HTTP. Another way to say the same thing is "your code doesn't wait for node.js to do stuff, like send data over TCP, because that's done asynchronously."

To answer your second question, I don't know which has less CPU load, I'm guessing they're similar. Node.js' touted advantage is the CPU is better utilized due to the aforementioned asynchronicity.

Yusuf X
  • 14,513
  • 5
  • 35
  • 47