Informazioni su NodeJS e non bloccanti IO

Question

Così, recentemente mi è stato iniettato il virus Node che si sta diffondendo nel mondo della Programmazione molto velocemente.

Sono affascinato dal suo approccio "Non-Blocking IO" e ho provato un paio di programmi.

Tuttavia, al momento non riesco a capire alcuni concetti.

ho bisogno di risposte in termini profani (qualcuno proveniente da un background di Java)

1. Multithreading & non-Blocking IO.

Consideriamo uno scenario pratico. Diciamo, abbiamo un sito web dove gli utenti possono registrarsi. Di seguito sarebbe il codice.

In un linguaggio di programmazione tradizionale, quanto sopra avviene in modo sequenziale. E, se ci sono più richieste di registrazione, il server web crea un nuovo thread e il resto è cronologia. Naturalmente, i programmatori possono creare i propri thread per lavorare su Line 2 e Line 3 contemporaneamente.

Nel nodo, come ho capito, le righe 2 & 3 verranno eseguite in parallelo mentre il resto del programma viene eseguito e l'interprete esegue il polling delle righe 2 & 3 ogni 'x' ms.

Ora, la mia domanda è, se il nodo è un linguaggio a thread singolo, che cosa fa il lavoro delle righe 2 & 3 mentre viene eseguito il resto del programma?

2. scalabilità

recente ho letto che LinkedIn hanno adattato nodo come back-end per il loro applicazioni mobili e visto notevoli miglioramenti.

Qualcuno può spiegare come ha fatto una tale differenza?

3. L'adattamento in altri linguaggi di programmazione

Se le persone affermano che nodo da facendo un sacco di differenza quando si tratta di prestazioni, perché non hanno altri linguaggi di programmazione adatti questo non-Blocking IO paradigma ?

sono sicuro che mi manca qualcosa. Solo se puoi spiegarmi e guidarmi con alcuni link, sarebbe utile.

Grazie.

Answer 1

Una domanda simile è stato chiesto e probabilmente contiene tutte le informazioni che state cercando: How the single threaded non blocking IO model works in Node.js

Ma mi occuperò brevemente i tuoi 3 parti:

1.
linee 2 e 3 in una forma molto semplice potrebbe essere:
            db.query (..., funzione (query_data) {...});
            fs.readFile ('/ path/to/file', la funzione (file_data) {...});

Ora la funzione (query_data) e funzione (file_data) sono callback. Le funzioni db.query e fs.readFile potranno inviare le richieste effettive di I/O, ma i callback consentono l'elaborazione dei dati dal database o il file per essere ritardata fino a quando si ricevono le risposte. In realtà non "esegue il polling delle righe 2 e 3". I callback vengono aggiunti a un loop eventi e associati ad alcuni descrittori di file per i rispettivi eventi I/O. Quindi esegue il polling dei descrittori di file per verificare se sono pronti per eseguire I/O. Se lo sono, esegue le funzioni di callback con i dati I/O.

credo che la frase "Tutto funziona in parallelo tranne che per il codice" riassume bene. Ad esempio, qualcosa come "Leggi i parametri HTTP" viene eseguita in sequenza, ma le funzioni di I/O come nelle righe 2 e 3 sono associate a callback che vengono aggiunte al loop eventi ed eseguite successivamente. Quindi, in pratica, l'intero punto è , non è necessario attendere l'I/O.

2.
causa delle cose spiegate in 1., Nodo scala bene per I/O intensive richieste e permette a molti utenti di essere collegati simultaneamente. È a thread singolo, quindi non è necessariamente scalabile per le attività a uso intensivo della CPU.

3.
Questo paradigma è stato usato con JavaScript perché JavaScript ha il supporto per i callback, loop di eventi e chiusure che rendono questo facile. Questo non è necessariamente vero in altre lingue.

potrei essere un po 'fuori, ma questo è il senso di ciò che sta accadendo.

Answer 2

Q1. "cosa fa il lavoro delle linee 2 & 3 mentre viene eseguito il resto del programma?" Risposta: "Niente". Le linee 2 e 3 sono ciascuna avviate i rispettivi lavori, ma tali lavori non possono essere eseguiti immediatamente perché (ad esempio) i settori del disco richiesti non sono ancora caricati - quindi il sistema operativo invia una chiamata al disco per ottenere quei settori , quindi "Nulla accade" (il nodo procede con il prossimo task) finché il sottosistema del disco (più tardi) emette un interrupt per segnalare che sono pronti, a quel punto il nodo restituisce il controllo alle linee 2 e 3.

Q2. il single-thread non-blocking non dedica quasi nessuna risorsa ad ogni connessione in entrata (solo alcuni dati di housekeeping sul socket connesso). È molto efficiente in termini di memoria. I server web tradizionali "forzano" un nuovo processo per gestire ogni nuova connessione, il che significa fare una copia gigantesca di ogni bit di codice e delle variabili di dati necessarie e affinare la CPU per far fronte a tutto. Questo è enormemente sprecante di risorse. Quindi - se il tuo carico è un sacco di connessioni inattive che attendono roba, come le loro, il nodo rende più carichi i carichi.

Q3. quasi tutti i linguaggi di programmazione dispongono già di I/O non bloccanti se si desidera utilizzarli. Il nodo non è un linguaggio di programmazione, è un server Web che esegue javascript e utilizza I/O non bloccante (ad esempio: ho personalmente scritto la mia stessa cosa 10 anni fa in perl, così come google (in C) quando hanno iniziato, e Sono sicuro che un sacco di altre persone hanno server web simili). L'I/O non bloccante non è la parte difficile: far capire al programmatore come usarlo è un po 'complicato. Javascript funziona bene, perché quei programmatori hanno già familiarità con la programmazione degli eventi.

Answer 3

Sebbene nodo.js è in giro da alcuni anni, il suo modello di prestazioni è ancora un po 'misterioso.

Recentemente ho avviato un blog e ho deciso che il modello node.js sarebbe stato un buon argomento in primo luogo poiché volevo capire meglio me stesso e sarebbe stato utile per gli altri condividere ciò che ho imparato. Qui ci sono un paio di articoli che ho scritto che spiegano i concetti di alto livello e alcuni compromessi:

Blocking vs. Non-Blocking I/O – What’s going on?

Understanding node.js Performance