Действительно ли Node.js увеличивает масштабируемость?

Я читал о проблеме C10K, и особое внимание уделено той части, которая относится к асинхронному серверу ввода-вывода. http://www.kegel.com/c10k.html#aio

Я полагаю, что это в значительной степени суммирует то, что Node.js делает на сервере, позволяя потокам обрабатывать запросы пользователей, полагаясь на прерывания (события) ввода-вывода, чтобы уведомлять потоки о выполненных заданиях, вместо того, чтобы поток отвечал за полная загрузка процессора. Поток может заниматься другими делами (неблокирующими) и получать уведомления о том, когда работа выполнена (например, найден файл или сжато видео).

Впоследствии это означает, что поток более «доступен» для сокетов и, следовательно, для пользователей на сервере.

Тогда я нашел это: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

Автор здесь утверждает, что хотя управляемая событиями структура (прерванная многопоточность) может освободить потоки, она фактически не уменьшает объем работы, которую должен выполнять процессор! Обоснование здесь заключается в том, что если, скажем, пользователь запрашивает сжатие загруженного видео, ЦП все равно должен фактически выполнить эту работу и будет блокировать, пока это делает (для простоты, давайте забудем о параллелизме здесь - если вы не знаю лучше!).

Я простой программист, а не администратор сервера или что-то в этом роде. Мне просто интересно узнать: является ли Node.js даром богов «облачных вычислений» или это все горячая тема, и не будет ли экономить время и / или деньги компаний за счет улучшения масштабируемости?

Большое спасибо.

Конечно, любая связанная с процессором работа будет использовать процессор. Он будет блокировать процессор на любом языке или структуре, на которой вы его пишете.

Node.js отлично подходит, когда у вас есть работа, связанная с вводом / выводом, а не с процессором. Я бы не стал делать тяжелую работу в Node, хотя это можно сделать. Node.js решает реальные проблемы, а не вымышленные или воображаемые, как серверы чисел Фибоначчи . Это не «горячий воздух».

Хотя документ C10K несколько устарел в отношении деталей реализации, параллелизм на основе событий (модель реактора) все еще в некоторых отношениях превосходит упреждающее планирование. Например, модель с вытесняющим планированием может планировать потоки, пока они заблокированы IO. Это позволяет узлу (и другим инструментам, таким как Ruby's Event Machine и Python's Twisted) лучше использовать доступные циклы, тратя больше времени на реальную работу и меньше блокируя время.

Многопоточность все еще повышает производительность. Оригинальное объяснение является идиотским, поскольку оно не учитывает существование нескольких ядер. В тот момент, когда у вас есть более одного ядра, потоки перестают быть потоками Это гиперпотоки. Любое поточно-интенсивное приложение получит от этого больше пользы, чем однопоточное.