Event Loop vs Blocco multithread IO

Question

Stavo leggendo un commento sull'architettura del server.

http://news.ycombinator.com/item?id=520077

In questo commento, la persona dice 3 cose:

1. il ciclo degli eventi, di volta in volta, ha dimostrato di brillare veramente per un alto numero di connessioni a bassa attività.
2. In confronto, è stato mostrato un modello di IO di blocco con thread o processi, volta per volta, per ridurre la latenza su una base di richiesta rispetto a un ciclo di eventi.
3. Su un sistema leggermente caricato la differenza è indistinguibile. Sotto carico, molti loop di eventi scelgono di rallentare, la maggior parte dei modelli di blocco sceglie di perdere il carico.

Qualcuno di questi è vero?

E anche un altro articolo qui dal titolo "Perché gli eventi sono una cattiva idea (per server ad alta concorrenza)"

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Answer 1

In genere, se si prevede che l'applicazione gestirà milioni di connessioni, è possibile combinare il paradigma multi-threaded con eventi.

1. Innanzitutto, genera come N thread dove N == numero di core/processori sulla macchina. Ogni thread avrà una lista di socket asincroni che dovrebbe gestire.
2. Quindi, per ogni nuova connessione dall'accettatore, "load-balance" il nuovo socket nella thread con il numero minore di socket.
3. All'interno di ogni thread, utilizzare il modello basato su eventi per tutti i socket, in modo che ogni thread possa effettivamente gestire più socket "contemporaneamente".

Con questo approccio,

1. Non si può mai generare un milione di discussioni. Hai solo tutto ciò che il tuo sistema può gestire.
2. Si utilizza evento basato su multicore anziché su un singolo core.

Answer 2

Non sei sicuro di cosa si intende per "bassa attività", ma credo che il maggiore il fattore sarebbe quanto devi effettivamente fare per gestire ogni richiesta. Supponendo un ciclo di eventi a thread singolo, nessun altro client avrebbe ricevuto le sue richieste gestite mentre si gestiva la richiesta corrente. Se hai bisogno di fare un sacco di cose per gestire ogni richiesta ("lotti" che significano qualcosa che richiede una CPU e/o un tempo significativo), e assumendo che la tua macchina sia effettivamente in grado di multitasking in modo efficiente (che prendere tempo non significa aspettare un condiviso risorsa, come una singola CPU o simile), si otterrebbe prestazioni migliori con il multitasking. Il multitasking potrebbe essere un modello di blocco multithreaded, ma potrebbe anche essere un ciclo di eventi single-tasking che raccoglie le richieste in arrivo, trasformandole in una fabbrica di lavoro multithread che le gestirà a turno (tramite multitasking) e inviandole una risposta al più presto.

Non credo che le connessioni lente con i client contino tanto, come direi che il sistema operativo gestirà in modo efficiente al di fuori della tua app (supponendo che tu non blocchi il ciclo di eventi per più roundtrip con il client che inizialmente ha avviato la richiesta), ma non l'ho mai testato personalmente.