Чи дійсно 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 дещо застарілий щодо деталей щодо впровадження, паралельність на основі подій (модель реактора) все ще певним чином перевершує попереднє планування. Наприклад, модель попереднього планування планування може планувати потоки, поки вони блокуються введення-виведення. Це дозволяє вузлу (та іншим інструментам, таким як Ruby’s Event Machine і Python's Twisted) краще використовувати доступні цикли, витрачаючи більше часу на реальну роботу та менше блокування часу.

Багатопоточність все ще підвищує продуктивність. Оригінальне пояснення є ідіотичним, оскільки не враховує існування декількох ядер. У момент, коли у вас є більше одного ядра, нитки вже не є потоками. Вони - гіпертоки. Будь-яке інтенсивне додаток для поточного потоку виграє від цього більше, ніж одна потокова програма.