6 ms·

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 o

by 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
- piccadilly 15y ago
  Well, there is plenty of point avoiding blocking on IO if blocking on IO is your bottleneck, and blocking on CPU is not. For some reason, a lot of people have focused on that case for many years.
- christkv 15y ago
  Most web applications are io bound not cpu bound as they spend most of their time talking to other systems across the network like your db or queue or some rest service. the cost of spinning up threads is memory and context switches by the os. Async is just a way to avoid this for io operations. Node.js is just an incredibly convenient way of doing this as there are less ways of shooting yourself in the foot than if you apply the async patterns to other tech platforms. Cpu bound is still cpu bound on any tech platform and needs another strategy to deal with it. I think it's better to look at node.js as a tool in your toolbox that is well adapted to running high load web-services and apps that are io bound instead of a swiss army-knife that does everything great. But as any toolbox you need more tools in the box to be a good carpenter. That includes picking tech that can do the cpu bound stuff in a appropriate manner, be it java, scala, c++, erlang whatever. You don't write a graph database in node.js unless you are masochistic. Just as you hopefully don't write an async server in assembly. From my usage perspective node.js is great for my async needs and the low resource usage means I need less hardware to scale my typical web app.
  - wyuenho 15y ago
    True, but wouldn't just making IO async be enough?
    - christkv 15y ago
      Yes it would and in fact most language platforms have async io. It's just harder to keep your yourself from introducing blocking calls in your event loop as they come with mostly blocking libs :)
wyuenho 15y ago
How is running 40 instances of node processes different from running 40 instances of a single threaded web server? How is running 40 instances of single threaded event loops better than running 10 instances of a process with 4 threads each? If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? Threads are too hard to program to? Try STM? I'm not buying the notion that node's event model has any advantage over anything whatsoever. Try Erlang if you want a properly engineered, event-driven development environment.
- zohebv 15y ago
  > How is running 40 instances of node processes different from running 40 instances of a single threaded web server? 40 Instances of a single threaded webserver can block for I/O. If your webserver is 50% CPU bound this means that your CPU utilization is lower than in the case of a perfectly async system. You will serve fewer requests per second than an async framework. This is where the rule of thumb "no of threads = 2X no of cores" originates. Of course this rule wont work well for heavily I/O bound servers with high latency I/O. With node.js latency/IO percentage etc won't matter. > If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? It would be great to have a multithreaded async framework. However a multithreaded environment eventually ends up introducing several blocking I/O functions which Dahl wanted to avoid. Hence the choice of Javascript. node.js is one of a 100 possible solutions. Nobody insists that you use it. In fact I haven't even written a single line of node code. However I have done enough systems work to know the benefits of async programming. > Threads are too hard to program to? Try STM? STM can only handle scenarios that do not involve I/O. One of my colleagues was in the group at Microsoft tried STM with I/O that fell hard on their faces. Sure there are plenty of approaches - threads, actors, STM. Async programming is one such approach. If you want to write an async web server, right now node.js is the only solution. I think it might be possible to do a pure async web server in Haskell, as any IO gets captured in the type signature but I don't know of any async Haskell webserver framework. > I'm not buying the notion that node's event model has any advantage over anything whatsoever. You are basically asserting that async programming has no advantage over any other approach whatsoever. Having dug into hard disk device drivers, filesystems and caching for the Windows CE kernel, I would have killed to have a proper async I/O framework in CE from the ground up. We had a gazillion locks in the kernel modules, for gazillion data structures when all we really wanted to do was perform I/O without grabbing a lock. The Linux epoll, BSD kqueue and Windows IO completion ports are all async APIs added for high performance systems. These APIs are, strictly speaking, not required if you have threads but when you get into sufficiently advanced systems programming you cannot live without these. Trying to say that async programming is useless is equivalent to claiming that APIs such as epoll/kqueues are useless.
gizzlon 15y ago
If you use Python/Perl you will never really know the number of instances of the process to run Eh? Think you could do async IO in both Perl & Python (and C and erlang ..) years before node came along..

by zohebv 15y ago

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

piccadilly 15y ago
Well, there is plenty of point avoiding blocking on IO if blocking on IO is your bottleneck, and blocking on CPU is not. For some reason, a lot of people have focused on that case for many years.
christkv 15y ago
Most web applications are io bound not cpu bound as they spend most of their time talking to other systems across the network like your db or queue or some rest service. the cost of spinning up threads is memory and context switches by the os. Async is just a way to avoid this for io operations. Node.js is just an incredibly convenient way of doing this as there are less ways of shooting yourself in the foot than if you apply the async patterns to other tech platforms. Cpu bound is still cpu bound on any tech platform and needs another strategy to deal with it. I think it's better to look at node.js as a tool in your toolbox that is well adapted to running high load web-services and apps that are io bound instead of a swiss army-knife that does everything great. But as any toolbox you need more tools in the box to be a good carpenter. That includes picking tech that can do the cpu bound stuff in a appropriate manner, be it java, scala, c++, erlang whatever. You don't write a graph database in node.js unless you are masochistic. Just as you hopefully don't write an async server in assembly. From my usage perspective node.js is great for my async needs and the low resource usage means I need less hardware to scale my typical web app.
- wyuenho 15y ago
  True, but wouldn't just making IO async be enough?
  - christkv 15y ago
    Yes it would and in fact most language platforms have async io. It's just harder to keep your yourself from introducing blocking calls in your event loop as they come with mostly blocking libs :)

wyuenho 15y ago

How is running 40 instances of node processes different from running 40 instances of a single threaded web server? How is running 40 instances of single threaded event loops better than running 10 instances of a process with 4 threads each? If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? Threads are too hard to program to? Try STM? I'm not buying the notion that node's event model has any advantage over anything whatsoever. Try Erlang if you want a properly engineered, event-driven development environment.

zohebv 15y ago
> How is running 40 instances of node processes different from running 40 instances of a single threaded web server? 40 Instances of a single threaded webserver can block for I/O. If your webserver is 50% CPU bound this means that your CPU utilization is lower than in the case of a perfectly async system. You will serve fewer requests per second than an async framework. This is where the rule of thumb "no of threads = 2X no of cores" originates. Of course this rule wont work well for heavily I/O bound servers with high latency I/O. With node.js latency/IO percentage etc won't matter. > If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? It would be great to have a multithreaded async framework. However a multithreaded environment eventually ends up introducing several blocking I/O functions which Dahl wanted to avoid. Hence the choice of Javascript. node.js is one of a 100 possible solutions. Nobody insists that you use it. In fact I haven't even written a single line of node code. However I have done enough systems work to know the benefits of async programming. > Threads are too hard to program to? Try STM? STM can only handle scenarios that do not involve I/O. One of my colleagues was in the group at Microsoft tried STM with I/O that fell hard on their faces. Sure there are plenty of approaches - threads, actors, STM. Async programming is one such approach. If you want to write an async web server, right now node.js is the only solution. I think it might be possible to do a pure async web server in Haskell, as any IO gets captured in the type signature but I don't know of any async Haskell webserver framework. > I'm not buying the notion that node's event model has any advantage over anything whatsoever. You are basically asserting that async programming has no advantage over any other approach whatsoever. Having dug into hard disk device drivers, filesystems and caching for the Windows CE kernel, I would have killed to have a proper async I/O framework in CE from the ground up. We had a gazillion locks in the kernel modules, for gazillion data structures when all we really wanted to do was perform I/O without grabbing a lock. The Linux epoll, BSD kqueue and Windows IO completion ports are all async APIs added for high performance systems. These APIs are, strictly speaking, not required if you have threads but when you get into sufficiently advanced systems programming you cannot live without these. Trying to say that async programming is useless is equivalent to claiming that APIs such as epoll/kqueues are useless.

gizzlon 15y ago

If you use Python/Perl you will never really know the number of instances of the process to run Eh? Think you could do async IO in both Perl & Python (and C and erlang ..) years before node came along..