[wyuenho]

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]

> 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.

[ajd]

@zohebv there are several errors in deduction here:

> a multithreaded environment eventually ends up introducing several blocking I/O functions

really? multi-threading and non blocking io are two separate tools and one doesn't have to choose one of them exclusively. they can be intertwined, boost::asio allows you to run a single async event processor on as many threads you want. all without doing any explicit locking. if you're averse to locking (which based on your experience seems to be the case) you're taking things too far by avoiding threads completely.

> You are basically asserting that async programming has no advantage over any other approach whatsoever

i don't think anyone's asserting that. the original argument made was - if all you have in one process is a tight loop dispatching non blocking io handlers then you can't handle computationally intensive tasks. of course, you can spawn 40 other process - but i don't like a model where that's your /only/ option. there are middle grounds and any system that discounts them is short sighted.

> Trying to say that async programming is useless

yet again. i don't see that being said anywhere.

> Node is an asynchronous programming framework bundled with a largely async library ... If you have done any kind of systems programming, you would know that availability of asynchronous I/O is a life saver

now, if you'd indulge me with my own escapades in logic and word play.

icing is sugar whipped in butter. if you have eaten any desert, you'd know that sugar is nice and tastes very sweet. thus, conclusively, irrevocably, icing is good and we shall eat nothing else.

[zohebv]

> @zohebv there are several errors in deduction here:

@ajd I would disagree with this statement very easily and very confidently.

> really

yes

> multi-threading and non blocking io are two separate tools

asio is a way of minimizing the number of threads in a system and extracting maximum performance.

> i don't think anyone's asserting that

It follows by logical deduction. There are only 3 possible criticisms of node.js 1. I need shared memory 2. I dislike Javascript 3. I dislike asio

Given that the cancer post doesn't make a big deal of 1 and 2. you are left with 3. And if you read his follow up post he is again complaining about "event-loop" programming. Yes he is indeed complaining about asio. asio necessarily introduces event loops.

There is only one reason to use multiple threads over multiple pre-started processes. You need the shared memory. You should still be able to pull off shared memory in node but it can be cumbersome. I am yet to see anyone complain about needing shared memory and hence disliking nodejs. Its either

1. "threads are robust for cpu bound workloads"

- which can be solved by simply launching as many nodejs processes as Python processes, though you only need to launch as many nodejs instances as cores if you are not interested in winning this argument.

2. "Don't force this programming model on me"

It is not forcing any programming model on you except that shared memory is harder. And yes you cannot acquire a lock and go off and do io. If you want to do that then you can, by piling up pending events in a queue, but the ugliness of the code will stick out easily. You might as well switch to Python/Java threads or whatsoever.

> of course, you can spawn 40 other process - but i don't like a model where that's your /only/ option

Can you describe the other options you want to try?

Check this out http://teddziuba.com/2011/10/straight-talk-on-event-loops.ht... He has broken down his own defense with his fancifully named "Theorem 2". If you do more IO than CPU then "use more threads". Except he doesn't give you the number of threads because he doesn't know how many. In fact, he cannot know. And this is why asio is a win.

Fact is on an n-core system if you launch n nodejs processes you are guaranteed one of the 4 hold true 1. You service all requests thrown at the system 2. You maximize the CPU utilization 3. You maximize I/O utilization 4. You maximize RAM utilization - "4. is some what pedantic"

i.e. it will extract the maximum possible performance from the hardware you throw at it. It is just a consequence of making sure all io is non blocking. With a threaded solution you will never get the number of threads right and you will end up with a server that cannot serve all requests even when it has spare CPU, spare I/O capacity and spare RAM. Maximizing CPU utilization implicitly assumes the absence of locks. If you use asio as well as locks CPU utilization will not be maximized. This is something that most of the "nodejs" critics don't understand or fail to appreciate.

Yes shared memory is harder to do in node, but erlang doesn't do shared memory, Python cannot do threads sensibly, Java cannot do coroutines, why dump hate on nodejs because it isn't an ideal environment for a solution that requires shared memory? Sure there are many problems that require shared memory. However 95% of webservers don't fall into this category.

Lastly ted's inexperience really shows here, he is only 27 years old and has a lot left to learn. To start with he can stop trying to school Ryan Dahl, who is someone who certainly knows his Computer Science and is making a valuable contribution to the community.

Lastly as a practical exercise, try to build (at least as a thought experiment) some web service that outperforms node using respected platforms such as Python and Ruby. asio is a technique for IO bound loads but node will do better than Ruby/Python even on CPU bound loads thanks to V8. An order of magnitude faster. I have said that you need to have n processes for n cores, but in practice it seems just one process turns out to be enough as loads tend to be io bound and V8 is typically 10 times faster than Ruby. And if you have coroutines event based programming is not hard at all. So yes people have discovered that one nodejs process has replaced their two dozen Ruby processes and is serving out twice as many requests from the same box and they are impressed. And they don't care about what Ted thinks.

As a footnote, of course, you can do shared memory within a single nodejs process(trivially true), but for pure CPU workloads Java/C++ would probably be a better option.

[ajd]

>>> a multithreaded environment eventually ends up introducing several blocking I/O functions

>> really?

> yes

ok.

> Can you describe the other options you want to try?

http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/exa.... See HTTP Server 1 to 4.

my issue with node is independent of the programming language. i came here neither to bury ted nor to praise him. i don't care what he has written now. i found his original article funny and thought that it had some truth in it. all the other "logical deductions" you're making, require axioms that you have and i don't. i don't know this ryan guy either but if he's made a system so many people (including yourself, who i admire sincerely) think so strongly about, he must be an all around great guy. good for him.

as for me and this discussion, if node=asio and threads=avoid in your world, so be it, i'm ok with that :)

> one nodejs process has replaced their two dozen Ruby processes and is serving out twice as many > requests from the same box and they are impressed

that says a lot about Ruby (with which i have absolutely no experience)

[zohebv]

As it so happens, I am now implementing a load balancing solution on the JVM using the hybrid technique you recommend, lots of threads and some asio coming soon. However asio support on the JVM is poor. You are correct, in that using asio does not preclude you from using threads and viceversa; while node.js does not let you use threads. Your argument is valid, but this is very different from the argument ted is making viz. a CPU bound task will make the server useless. This is demonstrably false, and ignores the fact that typical web workloads are io bound.

The C++ solution you posted is probably a hybrid solution as you described, but it has its own set of restrictions. The environment does not guarantee run time safety, functional programming support is poor and coroutine support is non-existent or weak(I noticed there is an unfinished Boost.coroutine library that must heavily depend on #include <functional>). While node shuts out threads it enables other solutions more suitable for a heavily I/O bound server. I only want to draw attention to the fact that almost all solutions available today involve some kind of compromise and hybrid solutions are possible in almost all of them.

As for the "deductions", I thought that they were obvious. You need threads rather than processes, so that you can share memory and avoid the serialization/deserialization complexity when communicating between threads. Or less often, you need a more elaborate synchronization mechanism such as reader/writer locks. As for asio extracting maximum performance, I think I will be better off writing a blog post about it.