Node.js aumenta effettivamente la scalabilità?

Ho letto del problema C10K e, in particolare, è la parte che si riferisce all'I / O del server asincrono. http://www.kegel.com/c10k.html#aio

Credo che questo riassuma praticamente ciò che Node.js fa sul server, consentendo ai thread di elaborare le richieste degli utenti facendo affidamento su interruzioni I / O (eventi) per notificare i thread dei lavori completati, anziché far sì che il thread sia responsabile del processo CPU completo. Il thread può andare avanti con altre cose (non bloccanti) ed essere avvisato quando viene fatto un lavoro (ad esempio, viene trovato un file o viene compresso un video).

Ciò significa in seguito che un thread è più "disponibile" per i socket e quindi per gli utenti sul server.

Poi ho trovato questo: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

Lo scrittore afferma che sebbene il framework basato sugli eventi (threading interrotto) possa liberare thread, in realtà non riduce la quantità di lavoro che una CPU deve fare! La logica qui è che se, per esempio, un utente richiede di comprimere un video che ha caricato, la CPU deve ancora effettivamente fare questo lavoro e bloccherà mentre lo fa (per amor di semplicità, dimentichiamoci del parallelismo qui - a meno che tu non conoscere meglio!).

Sono un programmatore diretto, non un amministratore di server o qualcosa del genere. Sono solo interessato a sapere: Node.js è un dono degli dei del 'cloud computing' o è tutta aria calda e non risparmierà effettivamente tempo e / o denaro alle aziende migliorando la scalabilità?

Grazie molto.

Ovviamente qualsiasi lavoro associato alla CPU utilizzerà la CPU. Bloccherà la CPU in qualsiasi lingua o framework in cui la scrivi.

Node.js è ottimo per quando si ha un lavoro di I / O associato, non associato alla CPU. Non farei un sollevamento pesante in Node, anche se può essere fatto. Node.js risolve problemi reali , non immaginari o immaginari come i server numerici fibonacci . Non è "aria calda".

Mentre il documento C10K è in qualche modo obsoleto per quanto riguarda i dettagli di implementazione, la concorrenza basata sugli eventi (il modello del reattore) è ancora in qualche modo superiore alla pianificazione preventiva. Ad esempio, un modello di pianificazione preventiva può pianificare thread mentre sono IO-bloccati. Ciò consente al nodo (e ad altri strumenti come Ruby's Event Machine e Python's Twisted) di utilizzare meglio i cicli disponibili trascorrendo più tempo a fare lavoro reale e meno a bloccare i tempi.

Il multithreading migliora ancora le prestazioni. La spiegazione originale è idiota in quanto non considera l'esistenza di più core. Nel momento in cui hai più di un core, i thread non sono più thread. Sono hyperthreads. Qualsiasi applicazione ad uso intensivo di thread ne trarrà beneficio più di una singola applicazione thread.