2010-03-24 14 views
8

Sto cercando di ottimizzare più connessioni per volta su un server socket TCP.Nuovo thread per connessione client nel server socket?

È considerata buona pratica, o addirittura razionale, avviare un nuovo thread nel server di ascolto ogni volta che ricevo una richiesta di connessione?

A che ora devo iniziare a preoccuparmi di un server basato su questa infrastruttura? Qual è il numero massimo di thread in background che posso lavorare, fino a quando non ha più senso?

Platform è C#, framework è Mono, sistema operativo di riferimento è CentOS, la RAM è 2.4G, il server è sulle nuvole, e mi aspetto circa 200 richieste di connessione al secondo.

risposta

8

No, non si dovrebbe avere un thread per connessione. Invece, dovresti utilizzare i metodi asincroni (BeginAccept/EndAccept, BeginSend/EndSend, ecc.). Questi renderanno molto più efficiente l'uso delle risorse di sistema.

In particolare, ogni thread creato aggiunge un sovraccarico in termini di interruttori di contesto, spazio di stack, mancate cache e così via. Linux è più bravo a gestire questa roba rispetto a Windows, ad esempio, ma non dovrebbe essere una scusa per darti il ​​libero dominio di creare tutti i thread che desideri;)

+0

@codeka E per quanto riguarda il processo per connessione. quando il client si connette al server. il server crea processi diversi e reindirizza il client ad esso? –

+0

Bene, è tecnicamente lo stesso con un processo per connessione. Ecco perché Apache (ad esempio) ora usa un pool di "processi di lavoro" per gestire le richieste simultanee, piuttosto che un processo per connessione. –

+1

+1 per menzionare i pool di thread ... potrebbe essere un buon approccio per l'implementazione di OP –