Node.js aumenta effettivamente la scalabilità?

21

Ho letto del problema C10K e, in particolare, la parte che fa riferimento all'I / O del server asincrono. link

Credo che questo riepiloghi quasi esattamente ciò che Node.js fa sul server, consentendo ai thread di elaborare le richieste degli utenti facendo affidamento sugli interrupt I / O (eventi) per notificare i thread dei lavori completati, piuttosto che avere il thread da responsabile del lavoro completo della CPU. Il thread può andare avanti con altre cose (non bloccanti) e ricevere una notifica di quando un lavoro viene eseguito (ad esempio, un file viene trovato o un video è compresso).

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

Poi ho trovato questo: link

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

Sono un programmatore semplice, non un amministratore del server o qualcosa del genere. Sono solo interessato a sapere: Node.js è un regalo degli dei del "cloud computing" o è tutto aria calda, e in realtà non farà risparmiare alle aziende tempo e / o denaro migliorando la scalabilità?

Grazie mille.

    
posta Alex 25.10.2011 - 15:37
fonte

3 risposte

20

Ovviamente qualsiasi lavoro legato alla CPU utilizzerà la CPU. Bloccherà la CPU in qualsiasi linguaggio o framework in cui la scrivi.

Node.js è ottimo per quando si ha un lavoro legato all'I / O, non alla CPU. Non farei pesanti lavori di sollevamento in Node, anche se può essere fatto. Node.js risolve problemi reali , non fittizi o immaginari come numero di fibonacci server . Non è "aria calda".

    
risposta data 25.10.2011 - 16:33
fonte
4

Sebbene il documento C10K sia in qualche modo obsoleto rispetto ai 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 i thread mentre sono bloccati dall'IO. Ciò consente al nodo (e ad altri strumenti come Ruby's Event Machine e Python's Twisted) di utilizzare al meglio i cicli disponibili impiegando più tempo a svolgere attività reali e meno tempo a bloccare.

    
risposta data 25.10.2011 - 18:15
fonte
-1

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 iperthreads. Qualsiasi applicazione thread-intensiva trarrà vantaggio da essa più di una singola applicazione con thread.

    
risposta data 26.05.2016 - 21:06
fonte

Leggi altre domande sui tag