Ce contenu a été discuté à plusieurs reprises sur les blogs cnblogs. J'ai lu des informations au cours des deux derniers jours et j'ai vu quelques indicateurs de performance simples et j'en ai discuté avec tout le monde.
Socket + Threads/ThreadPool
Performances approximatives : moins de 1500 connexions
Implémentation : Accepter un Socket et laisser la gestion à un thread C'est relativement stupide, mais c'est aussi plus efficace Parce que c'est une méthode synchrone, c'est très pratique à contrôler. La chose la plus avancée consiste à le confier à un pool de threads pour la gestion. Le pool de threads est automatiquement hébergé par le système, ce qui permet d'économiser le temps des threads en surcharge. Pour les petits projets généraux, cela est tout à fait suffisant et le développement est simple. Mais sachez que si plusieurs Sockets occupent des threads dans le pool de threads pendant une longue période et qu'il existe de nombreuses autres connexions, il est facile d'obtenir un message indiquant que vous n'avez pas suffisamment de threads à utiliser. Haha, c'est une bonne idée de laisser Socket faire moins de travail et prendre moins de temps. Passer à un processeur plus rapide est un bon moyen. De plus, s'il existe de meilleurs composants de pool de threads tiers, vous pouvez également choisir de les utiliser, tels que SmartThreadPool.
Prise + Sélection
Performances approximatives : Les performances diminuent après plus de 1 500 connexions.
Implémentation : Select est un modèle très couramment utilisé. Il s'agit d'interroger un ou plusieurs Sockets dans la fonction de blocage, et de placer le Socket à traiter dans une IList. Lorsque l'interrogation Select est terminée, nous traiterons ensuite nous-mêmes le Socket dans cette IList. Pour une utilisation spécifique, veuillez vous référer à MSDN. L'efficacité de Select ne peut pas être considérée comme élevée, car lorsqu'il y a de nombreux Sockets à traiter dans la file d'attente, traiter les derniers Sockets équivaut à parcourir tous les Sockets précédents, ce qui est très peu économique.
Socket+Asynchrone
Performances approximatives : environ 7500 connexions clients
Implémentation : BeginXXXX, EndXXXX, nous le connaissons tous. En dernière analyse, Socket asynchrone utilise toujours la technologie de pool de threads, utilisant le pool de threads pour gérer les E/S asynchrones. Cela soulève une autre question : quelle méthode d'implémentation est utilisée pour le pool de threads de .NET ? J'ai déjà vu quelqu'un dire que le pool de threads de .NET est implémenté à l'aide de ports de complétion. d'après les informations que j'ai trouvées (j'espère qu'un ami pourra me le dire). Le socket asynchrone est beaucoup plus compliqué que le flux de traitement d'un programme synchrone, et le contrôle des fonctions de rappel asynchrone n'est pas aussi intuitif que la méthode synchrone. Mais je pense qu'il convient de noter que la fonction de rappel doit être utilisée avec légèreté et ne doit pas gérer trop de transactions. Le traitement des données transférées doit être laissé à d'autres threads pour le traitement.
IOCP (port d'achèvement)
Performances approximatives : environ 20 000 à 50 000 connexions client
. Implémentation : Il existe des pseudo-IOCP sous .NET. Vous pouvez les rechercher. Je n'ai vu aucun exemple de SOCKET ouvert implémenté à l'aide de ces pseudo-IOCP. Les 20 000 à 50 000 connexions client dont je parle font référence à la situation de développement sous C++. Dans ce cas, les technologies de base qui doivent être utilisées incluent les pools de mémoire, les algorithmes de requête, etc.
Il n'y a aucune information pour vérifier le nombre maximum de connexions que le pseudo-IOCP peut réaliser. Si quelqu'un le sait, vous pouvez en discuter. De plus, la plupart des données mentionnées ci-dessus sont extraites de certaines informations. Je ne les ai pas essayées moi-même, je les présente simplement pour en discuter avec tout le monde. Je pense qu'un programme serveur hautes performances peut nécessiter une technologie qui ne concerne pas seulement le modèle à utiliser, mais également de nombreux détails auxquels il faut prêter attention, tels que le traitement de la mémoire, l'algorithme à utiliser, etc. uniquement en termes de coût logiciel, il y aura certainement un investissement dans le matériel.