TCP/IP - Risoluzione del C10K con l'approccio thread per client

Question

Dopo aver letto il famoso C10k article e aver cercato sul Web come sono evolute le cose da quando è stato scritto, vorrei sapere se sarebbe possibile per uno standard di oggi server per gestire > 10000 connessioni simultanee utilizzando un thread per connessione (eventualmente con l'aiuto di un pool di thread per evitare il processo di creazione/abbattimento).

---

Alcuni dettagli che possono influenzare l'approccio al problema:

1. input, elaborazione e output intermedio.
2. Lunghezza di ciascuna connessione.
3. Specifiche tecniche del server (nuclei, processori, RAM, ecc ...)
4. Combinando questo sistema con tecniche alternative come l'AIO, polling, fili verdi, ecc ...

---

Ovviamente non sono un esperto in materia, quindi qualsiasi commento o consiglio sarà molto apprezzato :)

Answer 1

Gli approcci usuali per i server sono: (a) thread per connessione (spesso con un pool di thread) o (b) single threaded con IO asincrono (spesso con epoll o kqueue). Il mio pensiero è che alcuni elementi di questi approcci possono, e spesso dovrebbero, essere combinati per utilizzare l'IO asincrono (con epoll o kqueue) e quindi passare la richiesta di connessione a un pool di thread da elaborare. Questo approccio combinerebbe l'invio efficiente dell'IO asincrono con il parallelismo fornito dal pool di thread.

Ho scritto un tale server per divertimento (in C++) che usa epoll su Linux e kqueue su FreeBSD e OSX insieme a un pool di thread. Ho solo bisogno di eseguirlo per test intensivi, fare un po 'di pulizia del codice e poi lanciarlo su github (speriamo presto).

Answer 2

Potrebbe interessarti un recente follow-up sull'argomento: The Secret To 10 Million Concurrent Connections -The Kernel Is The Problem, Not The Solution.

Answer 3

Assolutamente. Un server standard può gestire più di connessioni simultanee 10K utilizzando il modello con un thread per connessione. Ho creato un'applicazione di questo tipo e cinque anni fa era in esecuzione con più di 50.000 connessioni simultanee per processo su un server Linux standard. Al giorno d'oggi, dovrebbe essere possibile eseguire la stessa applicazione con più di 250.000 connessioni simultanee sull'hardware corrente.

ci sono solo un paio di cose da tenere a mente:

• discussioni riutilizzo utilizzando un pool di thread. Non è necessario eliminare i thread se non vengono utilizzati, poiché l'utilizzo delle risorse deve essere ottimizzato per i carichi di picco.
• Dimensioni stack: per impostazione predefinita, ogni thread Linux riserva 8 MB per il relativo stack. Questo riassume fino a 80 GB per i thread 10K. È necessario impostare la dimensione dello stack predefinita su un valore compreso tra 64k e 512k, che non è un problema, poiché la maggior parte delle applicazioni non richiede stack di chiamate più profondi.
• Se le connessioni sono di breve durata, ottimizzare per nuove connessioni creando più socket sullo stesso endpoint con l'opzione SO_REUSEPORT.
• Aumentare i limiti utente: open files (valore predefinito 1.024), max user processes
• Aumentare i limiti del sistema, ad es. /proc/sys/kernel/pid_max (predefinito 32 K), /proc/sys/kernel/threads-max e /proc/sys/vm/max_map_count (predefinito 65 K).

La domanda di cui sopra è stato inizialmente progettato per gestire solo 2K connessioni simultanee. Tuttavia, con la crescita in uso, non abbiamo dovuto apportare modifiche significative al codice per scalare fino a 50K connessioni.