Loop Evento vs multithread blocco IO

Question

ho letto un commento su un'architettura server.

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

In questo commento, la persona dice 3 cose:

1. Il ciclo di eventi, di volta in volta, ha dimostrato di brillare veramente per un elevato numero di connessioni a bassa attività.
2. In confronto, è stato dimostrato un modello IO blocco con fili o processi, di volta in volta, per ridurre la latenza su una base per-richiesta rispetto ad un ciclo di eventi.
3. In un sistema leggermente caricato la differenza è indistinguibile. Sotto carico, la maggior parte dei cicli di eventi scelgono di rallentare, la maggior parte dei modelli di blocco scelgono di far carico.

Qualcuno di questi veri?

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 l'applicazione è prevista per gestire milioni di connessioni, è possibile combinare paradigma multi-threaded con l'evento-based.

1. Per prima escursione come N fili dove N == numero di core / processori sulla macchina. Ogni thread avrà una lista di socket asincroni che si suppone di gestire.
2. Quindi, per ogni nuova connessione dal accettore, "load-balance" il nuovo zoccolo per il filo con il minor numero presa.
3. All'interno di ogni filo, utilizzare modello basato sugli eventi per tutte le prese, in modo che ogni filo può effettivamente gestire più prese "contemporaneamente."

Con questo approccio,

1. Non si può mai generare un milione di discussioni. Non vi resta che come molti come come sistema in grado di gestire.
2. Si utilizzano su multicore in contrapposizione ad un singolo core basato su eventi.

Answer 2

Non sei sicuro di cosa si intende per "attività di basso", ma credo che il fattore principale sarebbe quanto effettivamente necessario fare per gestire ogni richiesta. Supponendo un evento-loop single-threaded, nessun altro client otterrebbe loro richieste gestite mentre ha gestito la richiesta corrente. Se avete bisogno di fare un sacco di cose da gestire ogni richiesta ( "un sacco", cioè qualcosa che richiede notevole CPU e / o tempo), e assumendo la macchina in realtà è in grado di multitasking in modo efficiente (che prendendo il tempo non significa in attesa di un condiviso risorsa, come una singola macchina CPU o simile), si otterrebbe una migliore performance di multitasking. Multitasking potrebbe essere un modello di blocco multithread, ma potrebbe anche essere un singolo-tasking ciclo di eventi a raccogliere le richieste in arrivo, l'agricoltura fuori ad una fabbrica multithread operaio che avrebbe gestito quelli a sua volta (attraverso multitasking) e di inviare una risposta al più presto.

Non credo connessioni lente con i clienti importa più di tanto, come io crederei il sistema operativo avrebbe gestito in modo efficiente al di fuori della vostra applicazione (supponendo di non bloccare l'evento-loop per più di andata e ritorno con il cliente che inizialmente avviato la richiesta), ma non ho ancora testato questo me stesso.