Comment minimiser le nombre de threads utilisés dans une application serveur tcp?

Question

Je cherche des stratégies que les gens utilisent pour implémenter des applications serveur qui traitent les requêtes TCP (ou UDP) client: modèles de conception, techniques d'implémentation, meilleures pratiques, etc

Supposons aux fins de cette question que les demandes ont une durée de vie relativement longue (plusieurs minutes) et que le trafic est sensible au temps, donc aucun délai n'est acceptable pour répondre aux messages. De plus, nous répondons aux demandes des clients et établissons nos propres connexions avec d'autres serveurs.

Ma plate-forme est .NET, mais étant donné que la technologie sous-jacente est la même quelle que soit la plate-forme, je suis intéressé de voir les réponses pour toutes les langues.

Answer 1

L'approche moderne est d'utiliser le système d'exploitation pour multiplexer plusieurs sockets réseau pour vous, libérant ainsi l'application à ne traiter les connexions actives avec le trafic.

Chaque fois que vous ouvrez une prise, il il est associé à un sélecteur. Vous utilisez un seul thread pour interroger ce sélecteur. Chaque fois que des données arrivent, le sélecteur indique le socket qui est actif, vous passez cette opération à un thread fils et continuez l'interrogation.

De cette façon, vous avez seulement besoin d'un fil pour chaque opération concurrente. Les prises qui sont ouvertes mais inactives n'attachent pas un fil.

• Using the select() and poll() methods
• Building Highly Scalable Servers with Java NIO

Answer 2

G'day,

Je commence en regardant la métaphore que vous souhaitez utiliser pour votre cadre de fil. Peut-être "leader suiveur" où un thread écoute les demandes entrantes et lorsqu'une nouvelle requête arrive, le travail et le prochain thread dans le pool commence à écouter les demandes entrantes.

ou pool de threads où le même fil est toujours à l'écoute des demandes entrantes et passer ensuite les demandes sur le prochain fil disponible dans le pool de threads.

Vous aimeriez visiter la section Reactor des Composants Ace pour obtenir quelques idées.

HTH.

acclamations, Rob

Answer 3

serait une aproche plus sophosticated d'utiliser les ports IO achèvement. (Windows) Avec les ports d'achèvement d'E/S, vous laissez au système d'exploitation le soin de gérer l'interrogation, ce qui permet d'utiliser un très haut niveau d'optimisation avec la prise en charge du pilote de carte réseau. Fondamentalement, vous avez une file d'attente d'opérations réseau qui est gérée par le système d'exploitation et vous fournissez une fonction de rappel qui est appelée lorsque l'opération est terminée. Un peu comme DMA (Disque dur) mais pour le réseau.

Len Holgate a écrit une série eccelent sur les ports d'achèvement IO il y a quelques années sur CodeProject: http://www.codeproject.com/KB/IP/jbsocketserver2.aspx

Et je trouve un article sur les ports IO d'achèvement.net (ne l'ai pas lu cependant) http://www.codeproject.com/KB/cs/managediocp.aspx

Je voudrais aussi dire qu'il est facile d'utiliser les ports d'achèvement par rapport à essayer et écrire une alternative évolutive. Le problème est qu'ils ne sont disponibles que sur NT (2000, XP, Vista)

Answer 4

Si vous utilisiez directement C++ et Win32, je vous suggérerais de lire sur les ports d'E/S et de complétion d'E/S superposés . J'ai un framework C++, IOCP, client/serveur gratuit avec le code source complet, voir pour plus de détails.

Étant donné que vous utilisez .Net, vous devriez utiliser les méthodes de socket asynchrones pour ne pas avoir besoin d'un thread pour chaque connexion; Il ya plusieurs liens de ce blog qui peuvent être des points de départ utiles: http://www.lenholgate.com/blog/2005/07/disappointing-net-sockets-article-in-msdn-magazine-this-month.html (certains des meilleurs liens sont dans les commentaires à l'affichage original!)