Server TCP con boost :: asio, scalabilità del pool di thread e coroutine stackless

Question

Sto creando un daemon basato su TCP per la pre/post-elaborazione delle richieste HTTP. I client si collegheranno ad Apache HTTPD (o IIS) e un modulo Apache/IIS personalizzato inoltrerà richieste al mio daemon TCP per un'ulteriore elaborazione. Il mio demone dovrà aumentare (ma non uscire) per gestire un traffico significativo e la maggior parte delle richieste sarà di piccole dimensioni e di breve durata. Il demone sarà costruito in C++ e deve essere multipiattaforma.

Attualmente sto esaminando le librerie asio boost, che sembrano una scelta naturale. Tuttavia, ho difficoltà a comprendere i vantaggi del modello di poolless threadless coroutine vs thread. Nello specifico, sto guardando l'esempio del server HTTP n. 3 e l'esempio del server HTTP n. 4 qui: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html

Nonostante tutto il mio google, non riesco a comprendere appieno i meriti del server coroutine senza stack e come sarebbe eseguire relativamente al server del pool di thread su un sistema multi-core.

Quale dei due è più adatto alle mie esigenze e perché? Per favore, sentiti libero di 'mollare' le tue risposte riguardo l'idea di coroutine senza pila, sono ancora su un terreno instabile qui. Grazie!

Edit: Un altro caso pensiero/preoccupazione per la discussione: Boost server HTTP esempio # 4 è descritto come "un server HTTP a thread singolo implementato utilizzando coroutine stackless". OK, quindi è interamente single-threaded (giusto? Anche dopo il processo genitore 'fork' a un bambino? Vedere server.cpp nell'esempio # 4) ... il thread singolo diventerà un collo di bottiglia su un sistema multi-core? Suppongo che qualsiasi operazione di blocco impedirà l'esecuzione di tutte le altre richieste. Se questo è davvero il caso, per massimizzare il throughput sto pensando ad un evento asincrono di ricezione dati basato su coroutine, un pool di thread per le mie attività di blocco interno (per sfruttare i multi core), e quindi un meccanismo di connessione chiusa di invio asincrono &. Ancora una volta, la scalabilità è fondamentale. qualche idea?

Answer 1

Ho recentemente esaminato la scalabilità di boost.asio su macchine multi-core. La conclusione principale finora è che essa introduce in testa, contesa dei blocchi e cambi di contesto aggiuntive (almeno su Linux), vedere alcuni dei miei post del blog su questi argomenti:

• http://cmeerw.org/blog/748.html#748
• http://cmeerw.org/blog/751.html#751

ho anche iniziato un thread sulla mailing list ASIO per controllare che non ho perso nulla ovvio, vedere http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133

Se le preoccupazioni principali sono le prestazioni e la scalabilità poi sono Afra id, che non esiste una risposta chiara - potresti dover fare qualche prototipazione e guardare la performance.

Se si dispone di operazioni di blocco, si consiglia di utilizzare più thread. D'altra parte, il cambio di contesto e il conflitto di blocco possono ridurre le prestazioni con più thread (almeno sarà necessario prestare molta attenzione).

Modifica: solo per chiarire la roba senza coroutines: è essenzialmente solo un po 'di zucchero sintattico per rendere l'API asincrona un po' più simile alle chiamate sequenziali/di blocco.

Answer 2

È necessario misurare gli effetti per essere certi che cosa realmente accadere a causa della difficoltà di prevedere gli effetti relativi di località di riferimento, istruzioni della CPU la cache, i ritardi di programmazione, ecc

Se si desidera una supposizione euristica , considera che l'uso di n. thread con stack size S ognuno prende sempre nS byte tuttavia gran parte dello spazio di stack effettivamente utilizzato da ciascun thread. Se questo ti spinge oltre il confine della pagina, potrebbe diminuire le prestazioni in modo misurabile.