7 ms·

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the cho

I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys were really that irritated by this, you're going to be super pissed when you learn how computers work. I ain't even mad.

jjm 15y ago
If your using node and doing work other than serving simple pages, then your probably sending that work off. Most production serious Node-ers know not to do heavy lifting within the system. I really don't know where anyone from the Node community has ever recommended stuffing their single threaded V8 backed event processor with cpu heavy tasks. I still don't know why people are so maximist with their tools. NodeJS is a tool. It works well with your _other_ tools. There - is - no - perfect - tool, no perfect programmer, not even perfect intent.
- tedjdziuba 15y ago
  > Most production serious Node-ers know not to do heavy lifting within the system. So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself? > I still don't know why people are so maximist with their tools. Because moving parts = risk.
  - exogen 15y ago
    One Node process is reduced to doing the trivial work, like you'd have in any other system. Nothing is preventing the other processes from also being Node.
    - tedjdziuba 15y ago
      True, and in fact, this is how nginx works: the process that owns the event loop is separate from the process(es) that does the work. This is a decent way of mixing an event loop and multi-core processing, but with Node, you're forced to marry the HTTP server to the application, which is a dangerously tight coupling of responsibilities. If you really want to do something silly like write your application in server-side JS because you're familiar with it, then it should be through some interface like WSGI in Python (or even CGI in days of yore), which properly separates HTTP connection handling from application serving.
      - exogen 15y ago
        I'm not sure if many people are choosing Node just because they're familiar with JavaScript. Most people would probably rather be less familiar with JavaScript. More likely they're choosing it because the runtime is very fast and a lot of libraries are packaged for it. The WSGI/CGI bit is in fact mentioned in the article. :)
      - ricardobeat 15y ago
        You're not "forced to marry" the HTTP server to the application, you can keep them as separated as you want.
      - hampusw 15y ago
        There's nothing keeping you from running a separate web server and then proxying requests to Node using HTTP. Why is it a problem that you do this using HTTP? What alternative protocol would be so much better? FastCGI isn't really that different (each have their pros and cons) and CGI has obvious problems... WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).
  - jjm 15y ago
    It is up to you to figure things out based on possible worst case runtime scenario coupled with your expected usage on _your_ hardware. You choose what work is defined 'trivial' (based on your resources). Trivial is always moving, and dependent on the scenario at hand. My trivial is not your trivial. If the 'work' is too much you move it to another process. Either another NodeJS processor or some agnostic queue based managed worker. That worker could be anything. OR you decide to use another tool.
willvarfar 15y ago
But Ted, do you not understand that people use node.js because its a familiar language and a (relatively) fast runtime? Nobody has been using for computing fib though. Nobody has been putting in things that burn non-trivial amounts of CPU though. Its all about this: http://jlouisramblings.blogspot.com/2011/10/one-major-difference-zeromq-and-erlang.html http://jlouisramblings.blogspot.com/2011/10/one-major-differ...
j_baker 15y ago
I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.
- tedjdziuba 15y ago
  That's cool and all but in the real world we gotta get it done.
  - mbreese 15y ago
    Funny, because I avoid putting CPU intensive code in any request handler... in any language. if the calculation takes time, it's better done async. (and I don't even use node)
  - xnxn 15y ago
    Wait, I think I've missed something because that response seems overly dismissive. How is offloading CPU-intensive stuff to a worker system not getting it done?
    - ryanpers 15y ago
      because you dont fix everything with another layer of indirection. add in some more queuing (which as we know never has a problem) just to ger around 'no threads' seems stupid.
      - pork 15y ago
        um...the whole thing with asynchronous event-based processing is that you can (ideally) dispense with threads for many use cases.
        wlievens 15y ago
        You will have to do more of it, of course. In a classic thread-based system, it's okay if a single page takes a bit longer (e.g. >1 sec) to render if it's within your user's line of expectation. You can't do that here because you'll block all the others. But any decent developers knows that, so he takes the advantages Node.js offers and fixes the disadvantages that come along with it. Big deal. Is this discussion really only about the scalability tagline? Some taglines are misleading, really?
jeswin 15y ago
The problem is that fibonacci was a bad choice in your example and it proved nothing. It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation. If you do have tasks like that, process outside node and check for completion. Like how Tasks work in Google App Engine. Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node. Node and coffeescript has worked really well for us. Product coming out later this month. [EDIT: Just noticed that several other people pointed out the same thing. Looks like most node users are aware of potential problems, but I can see such issues being confusing for new users.]
- masklinn 15y ago
  > Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node. Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever). The fib example is extreme, but it's rooted into a real issue of cooperative multitasking: code does not always behave correctly and is not always perfect. You might have used a quadratic algorithm and it ran in 10ms on 10 items or so, but in production it happens a user is getting it to run on a hundred or a thousand items, and now other users are severely affected, in that their requests are completely frozen while the computation is going on. There are hundreds of other possibilities, small inefficiencies, shortcuts, plain bugs, etc... which are basically going to break your node application.
  - ricardobeat 15y ago
    Only if you're crazy enough to put something in production running a single node instance.
    - masklinn 15y ago
      Even if you're not "crazy enough" to do what's prescribed, every user routed to the locked node instance will still be locked. You're just reducing the surface area of the freeze.
ryanpers 15y ago
ted you're so cool be my friend pleaseeeee
zohebv 15y ago
Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests between two threads so that both requests are served in 10 seconds, instead of one request in 5 seconds and the next one in 10 seconds like the node.js solution. Does not sound much better. If you have done any kind of systems programming, you would know that availability of asynchronous I/O is a life saver, and can simplify your locking model greatly. 90% of the issues you face when building such systems is that some module deep inside grabbed a lock and issued a blocking I/O request and now the rest of the system is bottle necked behind it. Node.js is basically trying to eliminate the possibility of the existence of such a module. This complicates the issue of I/O calls, but simplifies locking in the sense that you don't really need all those locks in your system. In node.js of course there are no locks. The complexity moves from reasoning about locks to reasoning about correctly handling I/O calls and responses. IMO, this is the correct place to move the complexity to, because locks are simply an abstraction the programmer built. When debugging the system, we have to deal with - "How to get rid of this monolithic lock", when the real problem is - "This IO is taking too long we shouldn't be blocking on it". An async programming framework tackles this problem head on. If you use Python/Perl you will never really know the number of instances of the process to run, Too many and you time slice requests, slow down all of them, increase your queueing buffers instead of just dropping the extra requests. Too few processes and you start dropping requests that you could have served. With a framework like node.js the number of instances you want is equal to the number of cores on the server. Of course node.js can be an inappropriate solution for a wide variety of reasons, but I could not find anything really relevant regarding that in your post. Alex Payne discusses some issues here. You may want to read it. http://al3x.net/2010/07/27/node.html http://al3x.net/2010/07/27/node.html
- ittayd 15y ago
  The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU. Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations

jjm 15y ago

If your using node and doing work other than serving simple pages, then your probably sending that work off. Most production serious Node-ers know not to do heavy lifting within the system. I really don't know where anyone from the Node community has ever recommended stuffing their single threaded V8 backed event processor with cpu heavy tasks. I still don't know why people are so maximist with their tools. NodeJS is a tool. It works well with your _other_ tools. There - is - no - perfect - tool, no perfect programmer, not even perfect intent.

tedjdziuba 15y ago
> Most production serious Node-ers know not to do heavy lifting within the system. So Node is reduced to the trivial work? Then why make it unnecessarily hard on yourself? > I still don't know why people are so maximist with their tools. Because moving parts = risk.
- exogen 15y ago
  One Node process is reduced to doing the trivial work, like you'd have in any other system. Nothing is preventing the other processes from also being Node.
  - tedjdziuba 15y ago
    True, and in fact, this is how nginx works: the process that owns the event loop is separate from the process(es) that does the work. This is a decent way of mixing an event loop and multi-core processing, but with Node, you're forced to marry the HTTP server to the application, which is a dangerously tight coupling of responsibilities. If you really want to do something silly like write your application in server-side JS because you're familiar with it, then it should be through some interface like WSGI in Python (or even CGI in days of yore), which properly separates HTTP connection handling from application serving.
    - exogen 15y ago
      I'm not sure if many people are choosing Node just because they're familiar with JavaScript. Most people would probably rather be less familiar with JavaScript. More likely they're choosing it because the runtime is very fast and a lot of libraries are packaged for it. The WSGI/CGI bit is in fact mentioned in the article. :)
    - ricardobeat 15y ago
      You're not "forced to marry" the HTTP server to the application, you can keep them as separated as you want.
    - hampusw 15y ago
      There's nothing keeping you from running a separate web server and then proxying requests to Node using HTTP. Why is it a problem that you do this using HTTP? What alternative protocol would be so much better? FastCGI isn't really that different (each have their pros and cons) and CGI has obvious problems... WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).
- jjm 15y ago
  It is up to you to figure things out based on possible worst case runtime scenario coupled with your expected usage on _your_ hardware. You choose what work is defined 'trivial' (based on your resources). Trivial is always moving, and dependent on the scenario at hand. My trivial is not your trivial. If the 'work' is too much you move it to another process. Either another NodeJS processor or some agnostic queue based managed worker. That worker could be anything. OR you decide to use another tool.

willvarfar 15y ago

But Ted, do you not understand that people use node.js because its a familiar language and a (relatively) fast runtime? Nobody has been using for computing fib though. Nobody has been putting in things that burn non-trivial amounts of CPU though. Its all about this: http://jlouisramblings.blogspot.com/2011/10/one-major-difference-zeromq-and-erlang.html http://jlouisramblings.blogspot.com/2011/10/one-major-differ...

j_baker 15y ago

I would argue that heavily CPU-bound stuff shouldn't be run in a web app. It's much better to offload the task to a worker system via redis/zeromq/kestrel/etc. The majority of activity you see in every web app I've ever designed has been almost exclusively I/O bound.

tedjdziuba 15y ago
That's cool and all but in the real world we gotta get it done.
- mbreese 15y ago
  Funny, because I avoid putting CPU intensive code in any request handler... in any language. if the calculation takes time, it's better done async. (and I don't even use node)
- xnxn 15y ago
  Wait, I think I've missed something because that response seems overly dismissive. How is offloading CPU-intensive stuff to a worker system not getting it done?
  - ryanpers 15y ago
    because you dont fix everything with another layer of indirection. add in some more queuing (which as we know never has a problem) just to ger around 'no threads' seems stupid.
    - pork 15y ago
      um...the whole thing with asynchronous event-based processing is that you can (ideally) dispense with threads for many use cases.
      - wlievens 15y ago
        You will have to do more of it, of course. In a classic thread-based system, it's okay if a single page takes a bit longer (e.g. >1 sec) to render if it's within your user's line of expectation. You can't do that here because you'll block all the others. But any decent developers knows that, so he takes the advantages Node.js offers and fixes the disadvantages that come along with it. Big deal. Is this discussion really only about the scalability tagline? Some taglines are misleading, really?

jeswin 15y ago

The problem is that fibonacci was a bad choice in your example and it proved nothing. It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation. If you do have tasks like that, process outside node and check for completion. Like how Tasks work in Google App Engine. Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node. Node and coffeescript has worked really well for us. Product coming out later this month. [EDIT: Just noticed that several other people pointed out the same thing. Looks like most node users are aware of potential problems, but I can see such issues being confusing for new users.]

masklinn 15y ago
> Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node. Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever). The fib example is extreme, but it's rooted into a real issue of cooperative multitasking: code does not always behave correctly and is not always perfect. You might have used a quadratic algorithm and it ran in 10ms on 10 items or so, but in production it happens a user is getting it to run on a hundred or a thousand items, and now other users are severely affected, in that their requests are completely frozen while the computation is going on. There are hundreds of other possibilities, small inefficiencies, shortcuts, plain bugs, etc... which are basically going to break your node application.
- ricardobeat 15y ago
  Only if you're crazy enough to put something in production running a single node instance.
  - masklinn 15y ago
    Even if you're not "crazy enough" to do what's prescribed, every user routed to the locked node instance will still be locked. You're just reducing the surface area of the freeze.

ryanpers 15y ago

ted you're so cool be my friend pleaseeeee

zohebv 15y ago

Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests between two threads so that both requests are served in 10 seconds, instead of one request in 5 seconds and the next one in 10 seconds like the node.js solution. Does not sound much better. If you have done any kind of systems programming, you would know that availability of asynchronous I/O is a life saver, and can simplify your locking model greatly. 90% of the issues you face when building such systems is that some module deep inside grabbed a lock and issued a blocking I/O request and now the rest of the system is bottle necked behind it. Node.js is basically trying to eliminate the possibility of the existence of such a module. This complicates the issue of I/O calls, but simplifies locking in the sense that you don't really need all those locks in your system. In node.js of course there are no locks. The complexity moves from reasoning about locks to reasoning about correctly handling I/O calls and responses. IMO, this is the correct place to move the complexity to, because locks are simply an abstraction the programmer built. When debugging the system, we have to deal with - "How to get rid of this monolithic lock", when the real problem is - "This IO is taking too long we shouldn't be blocking on it". An async programming framework tackles this problem head on. If you use Python/Perl you will never really know the number of instances of the process to run, Too many and you time slice requests, slow down all of them, increase your queueing buffers instead of just dropping the extra requests. Too few processes and you start dropping requests that you could have served. With a framework like node.js the number of instances you want is equal to the number of cores on the server. Of course node.js can be an inappropriate solution for a wide variety of reasons, but I could not find anything really relevant regarding that in your post. Alex Payne discusses some issues here. You may want to read it. http://al3x.net/2010/07/27/node.html http://al3x.net/2010/07/27/node.html

ittayd 15y ago
The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU. Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations