Czy Node.js faktycznie zwiększa skalowalność?

Czytałem o problemie z C10K, a na szczególną uwagę zasługuje ta część, która odnosi się do asynchronicznego I / O serwera. http://www.kegel.com/c10k.html#aio

Wierzę, że to w zasadzie podsumowuje to, co robi Node.js na serwerze, pozwalając wątkom przetwarzać żądania użytkowników, polegając na przerwaniach I / O (zdarzeniach) w celu powiadamiania wątków o zakończonych zadaniach, a nie tym, że wątek jest odpowiedzialny za pełne zadanie procesora. Wątek może zająć się innymi rzeczami (nieblokującymi) i być powiadamiany o zakończeniu zadania (np. Znalezieniu pliku lub skompresowaniu wideo).

Oznacza to następnie, że wątek jest bardziej „dostępny” dla gniazd, a zatem dla użytkowników na serwerze.

Potem znalazłem to: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

Autor tutaj twierdzi, że chociaż platforma sterowana zdarzeniami (przerwane wątki) może zwolnić wątki, to tak naprawdę nie zmniejsza nakładu pracy procesora! Uzasadnieniem jest to, że jeśli, powiedzmy, użytkownik zażąda skompresowania przesłanego filmu, procesor nadal musi wykonać tę pracę i będzie blokował się podczas jej wykonywania (dla uproszczenia, zapomnijmy o paralelności tutaj - chyba że wiedzieć lepiej!).

Jestem prostym programistą, nie jestem administratorem serwera ani nic takiego. Chciałbym tylko wiedzieć: czy Node.js jest prezentem od bogów „przetwarzania w chmurze”, czy to wszystko jest na gorącym powietrzu i nie zaoszczędzi czasu i / lub pieniędzy firmom dzięki poprawie skalowalności?

Wielkie dzięki.

Oczywiście każda praca związana z procesorem będzie wykorzystywać procesor. Będzie blokować procesor w dowolnym języku lub frameworku, w którym go napiszesz.

Node.js jest świetny, gdy masz pracę związaną z We / Wy, a nie procesor. Nie podnosiłbym ciężkiego podnoszenia w Węźle, choć da się to zrobić. Node.js rozwiązuje prawdziwe problemy, a nie fikcyjne lub wymyślone, takie jak serwery liczb Fibonacciego . To nie jest „gorące powietrze”.

Chociaż dokument C10K jest nieco nieaktualny w odniesieniu do szczegółów implementacji, współbieżność oparta na zdarzeniach (model reaktora) wciąż jest pod pewnymi względami lepsza niż harmonogram wyprzedzający. Na przykład model planowania zapobiegawczego może planować wątki, gdy są zablokowane we / wy. Dzięki temu węzeł (i inne narzędzia, takie jak Ruby's Event Machine i Python's Twisted) mogą lepiej wykorzystywać dostępne cykle, spędzając więcej czasu na prawdziwej pracy, a mniej na blokowaniu czasu.

Wielowątkowość wciąż zwiększa wydajność. Oryginalne wyjaśnienie jest idiotyczne, ponieważ nie uwzględnia istnienia wielu rdzeni. W momencie, gdy masz więcej niż jeden rdzeń, wątki nie są już wątkami. Są hipertekstami. Każda aplikacja intensywnie wykorzystująca wątek skorzysta z niej więcej niż jedna aplikacja wątkowa.