Voici un résumé des problèmes liés à la mise en œuvre d’un composant socket haute performance : si vous n’avez besoin que de gérer des milliers d’applications concurrentes, vous pouvez vous concentrer sur l’écriture du code, mais vous devez faire face à des dizaines de milliers ou des dizaines de milliers d’applications simultanées. Le résumé des questions suivantes est considéré comme d’une grande aide pour la rédaction de cette demande.
SocketAsyncEventArgs
Cet objet est fourni après .NET 2.0 sp1 et est principalement utilisé pour implémenter un traitement haute performance de l’envoi et de la réception de données sur socket (pour une introduction plus détaillée, vous pouvez consulter MSDN). Cet objet fournit trois façons de définir les tampons pour l’envoi et la réception liés : SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, les deux premiers ne peuvent pas coexister avec ces derniers ( MSDN explique pourquoi). Lorsque vous définissez un buffer, que ce soit SetBuffer(Byte(), Int32, Int32) ou BufferList, essayez de le configurer une seule fois par instance SocketAsyncEventArgs pendant la durée de vie du programme, car ce paramètre peut être très gourmand en ressources. Il est recommandé de configurer le tampon de données via SetBuffer(Byte(), Int32, Int32) lors de la construction de SocketAsyncEventArgs, puis d’utiliser SetBuffer (Int32, Int32) pour le gérer. Lorsque vous souhaitez définir une BufferList, il est préférable de ne pas changer <byte>la source de l’octet référencée par <ArraySegment>IList. Si cela est modifié, cela fera que SocketAsyncEventArgs reliera le tampon et affectera l’efficacité.
Pool SocketAsyncEventArgs
Comme mentionné plus haut, essayez de ne pas modifier autant que possible le tampon référencé par SocketAsyncEventArgs afin d’atteindre cet objectif. Il est donc nécessaire de construire un pool d’applications SocketAsyncEventArgs et d’initialiser l’objet SocketAsyncEventArgs autant que possible au début du programme. En plus de réduire la création de SocketAsyncEventArgs, la construction de pools permet également d’économiser beaucoup de mémoire. La raison principale est que vous ne pouvez pas savoir la taille de chaque message, bien sûr, vous pouvez donner une limite maximale au message avant de concevoir, puis définir le tampon correspondant à SocketAsyncEventArgs. Cependant, c’est un grand gaspillage de mémoire, car tous les messages n’ont pas une longueur maximale. Allouer une quantité appropriée de tampon aux SocketAsyncEventArgs, fournir des appels via des pools, et écrire des messages de manière flexible sur un ou plusieurs SocketAsyncEventArgs, ou stocker plusieurs messages dans un seul SocketAsyncEventArgs pour traitement.
file d’attente
Je vois que de nombreuses pratiques consistent à ouvrir les threads directement ou à les jeter dans le pool de threads après avoir reçu les données, ce qui est très mauvais car cela ne contrôle pas mieux le travail des threads, y compris l’attente des threads. Avec des threads personnalisés + files d’attente, vous pouvez contrôler combien de threads sont responsables de quel travail, et le travail en file d’attente n’existera que dans la file d’attente ; Il n’y aura pas un grand nombre de threads ni de lignes en attente, ce qui fera perdre des ressources au système d’exploitation à cause de l’ordonnancement des threads.
Consolidation retardée des données
La transmission retardée des données par fusion est un moyen de résoudre le problème des opérations d’E/S réseau excessives, ce qui n’est pas utilisé dans de nombreux scénarios, mais il est courant dans les serveurs de jeu. Quelqu’un m’a déjà posé une question : s’il y a 400 utilisateurs dans la scène, chaque changement d’environnement indiquera aux autres utilisateurs. Si les données combinées ne sont pas utilisées, cela produira une opération d’IO réseau très redoutante, difficile à transporter pour le système de numérotation d’opération IO. Il est donc nécessaire de fusionner et d’envoyer les données dans un intervalle de délai approprié pour l’application en cours. |
Publié sur 02/11/2016 09:53:37
|
|
|
