5 ms·

Troll. Post made no sense and came to no conclusion. "The content server should not need to do hardly any IO. Why would an HTML content server need to write to

Troll. Post made no sense and came to no conclusion. "The content server should not need to do hardly any IO. Why would an HTML content server need to write to the filesystem?" This just shows a blatant lack of knowledge about what constitues IO. FYI, network is IO, writing to console is IO, logging is IO. The point of an evented system like node (and others based around the 'select' or 'epoll' type calls is that you can use one thread to do other things when you are waiting for the kernel to tell you your socket is ready. Yes, I too get frustrated when 'front-end' people think they are systems engineers or super server coders, but that doesn't mean I am going to write a blog post that goes nowhere about it and completely misses the point of an evented system like this.

shuzchen 15y ago
Post also shows a blatant lack of knowledge about what an event loop is. Node and Tornado (two event-loop based servers) are by design single-threaded. This is because for certain setups, having a separate thread for each connected client (the norm for something like Apache) can destroy your server. IMO the main problem that event loop systems were designed to solve was the "I have a ton of people connected concurrently but the majority of the time these connections are idle". Think if you were building a chat application. Your users are connected to your service constantly (they want to get messages as soon as they arrive), but most of the time they AREN'T receiving or sending data. If you had a thread for every connected client your server would melt due to the ram overhead, even though most threads aren't doing any work 99% of the time. In an event-loop based system, you don't have this issue because everything gets handled by one thread.
- MostAwesomeDude 15y ago
  Yes and no. The problem solved by event loops is the problem solved by select(): You never want to wait for a single person to do something; you want to wait for anybody to do anything.
  - nakkiel 15y ago
    You certainly mean "the problem solved by select() alternatives such as kqueue(), epoll(), etc..". :)
edtechre 15y ago
Not a troll. The post's point was that for your average web app, NodeJS doesn't solve any problems. If you were building some kind of real time app like the Facebook social stream, then yes, it may make sense. But for your run of the mill web app that still treats HTTP as a fire & forget stateless protocol, then NodeJS isn't going to give you any advantage. In fact, its single threaded design will prove to be far more disadvantageous than going with a setup of nginx and PHP/Ruby/Python.

shuzchen 15y ago

Post also shows a blatant lack of knowledge about what an event loop is. Node and Tornado (two event-loop based servers) are by design single-threaded. This is because for certain setups, having a separate thread for each connected client (the norm for something like Apache) can destroy your server. IMO the main problem that event loop systems were designed to solve was the "I have a ton of people connected concurrently but the majority of the time these connections are idle". Think if you were building a chat application. Your users are connected to your service constantly (they want to get messages as soon as they arrive), but most of the time they AREN'T receiving or sending data. If you had a thread for every connected client your server would melt due to the ram overhead, even though most threads aren't doing any work 99% of the time. In an event-loop based system, you don't have this issue because everything gets handled by one thread.

MostAwesomeDude 15y ago
Yes and no. The problem solved by event loops is the problem solved by select(): You never want to wait for a single person to do something; you want to wait for anybody to do anything.
- nakkiel 15y ago
  You certainly mean "the problem solved by select() alternatives such as kqueue(), epoll(), etc..". :)

edtechre 15y ago

Not a troll. The post's point was that for your average web app, NodeJS doesn't solve any problems. If you were building some kind of real time app like the Facebook social stream, then yes, it may make sense. But for your run of the mill web app that still treats HTTP as a fire & forget stateless protocol, then NodeJS isn't going to give you any advantage. In fact, its single threaded design will prove to be far more disadvantageous than going with a setup of nginx and PHP/Ruby/Python.