7 ms·

Fast Facts on Node.js

25 points by sliggity 16y ago

spooneybarger 16y ago
I find a number of the fast facts to be horribly misleading due to their brevity... "Node.js runs everything in ‘parallel’, meaning that all of your tasks can be run at the same time. For example, let’s say you have a webpage that has 100 lines of code with 10 database calls. With a web server like Apache, these 10 database calls must be made in succession. While running node.js, you can run all 10 of these database calls at once, which makes the webpage load faster." errr... maybe... "Current web servers must open many connections to interact with their operating system (OS), while node.js only needs to open 1 connection. Each connection costs the system memory, so using fewer connections is more efficient and faster for the entire system." there are many lightweight polling webservers like nginx, lighttpd etc
- kmccarth 16y ago
  Hey Spooneybarger, I wrote that article. I by no means intended to mislead, I just wanted to keep it simple for a more mainstream audience to digest. In programming or technical environments, there are literally thousands of factors that come into play, so to avoid the inclusion of all of them, I kept it brief. Is there any different way you'd phrase the above?
  - axod 16y ago
    I'd get rid of the 'node.js runs everything in parallel' BS unless you can back it up with facts and numbers. It reads like complete rubbish atm. Also I have no idea what you're talking about with 'connections to the OS'. Sounds like more FUD to me. The code that makes up node.js is carried out by the V8 javascript engine. This engine (read: the component that processes javascript so that it can be understood by your operating system) is the same one Google uses in Chrome, which makes the processing of node.js very, very fast. It should also be noted here, that it makes it very, very fast "when compared to other js engines", however, it makes it pretty slow when compared to a ton of other languages/runtimes. It's just misleading marketing speak to omit that.
    - kmccarth 16y ago
      Looks like I was given some bad info, updating now
    - kmccarth 16y ago
      With regards to the 'connections to the OS', I was attempting to paraphrase this chunk from the official site: "Node's goal is to provide an easy way to build scalable network programs. In the "hello world" web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation. This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. See: this and this."
      - axod 16y ago
        Pretty much any webserver can do that though. Even apache can easily be setup to do that. So it's not really unique to node.js. Definitely a good design decision, but as I say, not unique to node.js.
    - JonnieCache 16y ago
      I think it is perfectly valid to heavily simplify things for a less-technical audience. The scientific models we teach kids in schools are simplified to the point of sometimes appearing outright wrong, however we don't go accusing science teachers of lying to or misleading our children. As long as there are no deliberate deceptions, and links are provided to resources that give a fuller picture, there is no problem. If all the resources surrounding a technology are written at the lowest possible level of understanding, that technology will never be able to gain traction outside the world of hackers. to the OP: maybe add a disclaimer to the effect of "Some of these points are simplifications, please read on elsewhere if interested to find out more"
      - axod 16y ago
- ez77 16y ago
  there are many lightweight polling webservers like nginx, lighttpd etc Question from a newbie: is there any disadvantage to polling? Allow me to digress a little. When I look at the benchmark comparisons between Apache and the new, lightweight crowd that there is no way a modest static site could serve anything reasonable back in 1995. I realize that in 1995 there was way less traffic, but some humble sites did get thousands of visits per hour. It looks like this can very well choke an Apache server with 2010 hardware! I guess my question could be rephrased thus: Why didn't the Apache folks take this lightweight path fifteen years ago, when it mattered much more? Any comments will be welcome.
kmccarth 16y ago
also, if anyone is an expert on node, please email me at kevin at bostinnovation dot com so I can fill in some of the holes in this article
- DTrejo 16y ago
  Stop into #node.js on irc.freenode.net, and see what feedback they have (if you haven't already).
deleted 16y ago
[deleted]
nestlequ1k 16y ago
Fast Fact: due to a v8 bug, a Node.js process currently only supports a max of 1.9gb of RAM http://code.google.com/p/v8/issues/detail?id=847 http://code.google.com/p/v8/issues/detail?id=847
- EGreg 16y ago
  That's fine if you are running a 16-core machine with 16GB of ram, isn't it? Just have one Node.js process per core.
  - nestlequ1k 16y ago
    Yep, easy enough to workaround. Seems like a needless limitation however. Would be nice if someone on node.js core (or v8 team at google) would try to fix that bug. Also wonder what other bugs are going to emerge as a result of trying to use a client side app on the server.
    - johnm 16y ago
      Do note clearly that V8's garbage collector is fairly slow (think old Java GC) so having more instances of node with smaller heaps is a good idea anyways.
      - EGreg 16y ago
        Argh, I was afraid of that. Can we have something that is a hybrid of refcounting and stop-the-world GC? I read some nice academic paper a few years ago about how people made a GC that combined the benefits of refcounting and stop the world.
  - johnm 16y ago
    Depending on your workload, 1 node per 2 cores is a better rule of thumb. Also, split the networking across multiple NICs.

25 points by sliggity 16y ago

I find a number of the fast facts to be horribly misleading due to their brevity... "Node.js runs everything in ‘parallel’, meaning that all of your tasks can be run at the same time. For example, let’s say you have a webpage that has 100 lines of code with 10 database calls. With a web server like Apache, these 10 database calls must be made in succession. While running node.js, you can run all 10 of these database calls at once, which makes the webpage load faster." errr... maybe... "Current web servers must open many connections to interact with their operating system (OS), while node.js only needs to open 1 connection. Each connection costs the system memory, so using fewer connections is more efficient and faster for the entire system." there are many lightweight polling webservers like nginx, lighttpd etc

kmccarth 16y ago
Hey Spooneybarger, I wrote that article. I by no means intended to mislead, I just wanted to keep it simple for a more mainstream audience to digest. In programming or technical environments, there are literally thousands of factors that come into play, so to avoid the inclusion of all of them, I kept it brief. Is there any different way you'd phrase the above?
- axod 16y ago
  I'd get rid of the 'node.js runs everything in parallel' BS unless you can back it up with facts and numbers. It reads like complete rubbish atm. Also I have no idea what you're talking about with 'connections to the OS'. Sounds like more FUD to me. The code that makes up node.js is carried out by the V8 javascript engine. This engine (read: the component that processes javascript so that it can be understood by your operating system) is the same one Google uses in Chrome, which makes the processing of node.js very, very fast. It should also be noted here, that it makes it very, very fast "when compared to other js engines", however, it makes it pretty slow when compared to a ton of other languages/runtimes. It's just misleading marketing speak to omit that.
  - kmccarth 16y ago
    Looks like I was given some bad info, updating now
  - kmccarth 16y ago
    With regards to the 'connections to the OS', I was attempting to paraphrase this chunk from the official site: "Node's goal is to provide an easy way to build scalable network programs. In the "hello world" web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation. This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. See: this and this."
    - axod 16y ago
      Pretty much any webserver can do that though. Even apache can easily be setup to do that. So it's not really unique to node.js. Definitely a good design decision, but as I say, not unique to node.js.
  - JonnieCache 16y ago
    I think it is perfectly valid to heavily simplify things for a less-technical audience. The scientific models we teach kids in schools are simplified to the point of sometimes appearing outright wrong, however we don't go accusing science teachers of lying to or misleading our children. As long as there are no deliberate deceptions, and links are provided to resources that give a fuller picture, there is no problem. If all the resources surrounding a technology are written at the lowest possible level of understanding, that technology will never be able to gain traction outside the world of hackers. to the OP: maybe add a disclaimer to the effect of "Some of these points are simplifications, please read on elsewhere if interested to find out more"
    - axod 16y ago
ez77 16y ago
there are many lightweight polling webservers like nginx, lighttpd etc Question from a newbie: is there any disadvantage to polling? Allow me to digress a little. When I look at the benchmark comparisons between Apache and the new, lightweight crowd that there is no way a modest static site could serve anything reasonable back in 1995. I realize that in 1995 there was way less traffic, but some humble sites did get thousands of visits per hour. It looks like this can very well choke an Apache server with 2010 hardware! I guess my question could be rephrased thus: Why didn't the Apache folks take this lightweight path fifteen years ago, when it mattered much more? Any comments will be welcome.

kmccarth 16y ago

also, if anyone is an expert on node, please email me at kevin at bostinnovation dot com so I can fill in some of the holes in this article

DTrejo 16y ago
Stop into #node.js on irc.freenode.net, and see what feedback they have (if you haven't already).

deleted 16y ago

[deleted]

nestlequ1k 16y ago

Fast Fact: due to a v8 bug, a Node.js process currently only supports a max of 1.9gb of RAM http://code.google.com/p/v8/issues/detail?id=847 http://code.google.com/p/v8/issues/detail?id=847

EGreg 16y ago
That's fine if you are running a 16-core machine with 16GB of ram, isn't it? Just have one Node.js process per core.
- nestlequ1k 16y ago
  Yep, easy enough to workaround. Seems like a needless limitation however. Would be nice if someone on node.js core (or v8 team at google) would try to fix that bug. Also wonder what other bugs are going to emerge as a result of trying to use a client side app on the server.
  - johnm 16y ago
    Do note clearly that V8's garbage collector is fairly slow (think old Java GC) so having more instances of node with smaller heaps is a good idea anyways.
    - EGreg 16y ago
      Argh, I was afraid of that. Can we have something that is a hybrid of refcounting and stop-the-world GC? I read some nice academic paper a few years ago about how people made a GC that combined the benefits of refcounting and stop the world.
- johnm 16y ago
  Depending on your workload, 1 node per 2 cores is a better rule of thumb. Also, split the networking across multiple NICs.