Mise en cache d'un flux réseau

Question

Mon programme C# reçoit beaucoup de données via plusieurs sockets et il semble que j'ai des problèmes de surcharge du cache TCP sur le noyau Windows.
Cela peut être vu par les résultats suivants du tcpdump du serveur:

18: 02: 18,963370 IP xxxx> yyyy.zzz:. ack 10017011 win 0

Quelle structure de données/stratégie utiliseriez-vous pour mettre en cache les données lues afin d'éviter la surcharge sur C#?
Je travaille actuellement avec un délégué pour chaque socket dans un thread séparé qui est appelé après chaque enregistrement lu, mais cela semble être un problème, de sorte que je pourrais avoir besoin de le diviser en deux threads.
Ou devrais-je envisager de peaufiner les paramètres TCP du côté Windows? J'utilise Windows 7.
Y at-il des livres pour l'optimisation du noyau?
J'ai été vraiment aveuglé que le programme est devenu plus lent même si la charge est d'environ 20-25% pour la machine complète et 50-60% sur le noyau le plus chargé.

Answer 1

Sans trop en savoir plus sur l'architecture de votre programme, je suppose que votre programme lui-même est le goulot d'étranglement. Si votre application n'utilise pas d'arrière-plan pour collecter les messages TCP et les stocker pour être consommés par le code qui effectue le «gros travail», alors votre programme lit le tampon existant, puis traite ce qu'il contient pendant que le tampon TCP se recharge . Ce cercle vicieux ne peut avoir qu'une seule fin; Finalement, le tampon débordera en attendant que votre programme finisse de traiter ce qu'il a reçu la dernière fois.

Je chercherais à refactoriser votre réception TCP dans un modèle de type ETL. Vous avez besoin d'un thread chargé d'écouter l'entrée TCP, d'extraire les données du tampon et de les mettre en file d'attente dans une collection visible par le reste du programme. Il ne devrait rien faire d'autre que de retirer les données du tampon et de placer les messages bruts dans cette file d'attente, et il devrait le faire aussi vite que possible.

Avec les messages reçus en mémoire, le reste de votre programme peut prendre presque autant de temps qu'il veut consommer chaque message. Vous devez toujours vous assurer que vous ne surchargez pas cette file d'attente en mémoire, mais comme un seul objet .NET peut référencer jusqu'à 2 Go de mémoire, vous risquez beaucoup moins de rencontrer des problèmes. Si vous débordez cette file d'attente dans le programme, vous devez soit rendre le traitement plus efficace, soit lancer plus de threads à cette deuxième étape du processus.