Performance Test et TCP tuning

Nous sums en train de tester la performance d'une application qui reçoit des requêtes tcp les convertit en requests de soap (WCF-httpBinding) sur lesquelles d'autres services fonctionnent.

Le server est Windows Server 2008 R2. Les requêtes TCP sont reçues par l'instance TcpListener (.NET C #). Il existe 3 services WCF liés à HTTP fonctionnant sur le même server.

Nous avons construit un client de test de performance qui vise à simuler de multiples requests simultanées (chaque request doit être différente et reconnaissable par l'application).

Nous avons construit un test exécutant 150 requêtes qui fonctionnent en même time (par 150 threads différents), et nous avons remarqué tout de suite que certaines requêtes obtiennent la connection TCP lentement, mais une fois qu'elles l'ont, elles agissent rapidement.

Une request unique écrit deux fois sur la même request de connection et une application ack.

Bien qu'une seule requête + ack puisse prendre environ 150 ms, le test 150 dure environ 7 secondes.

Le problème

Lorsque nous essayons d'exécuter ce test à partir de 2 ordinateurs différents, nous perdons des requests . certaines requests de clients obtiennent

no connection was made because the target machine actively refused it 

Je suis donc arrivé ici et je me suis persuadé que c'était à cause de l'arriéré. J'ai changé les parameters de TcpListener et les modifications apscopes à l'logging AFD de registre ont été écrites ici mais cela ne fonctionnait toujours pas. J'ai donc inséré tous les réglages TCP suggérés, plus certaines commands netsh qui ont été recommandées, mais toujours pas de changement, nous obtenons toujours cette erreur.

Y a-t-il autre chose que je dois savoir? Y a-t-il d'autres solutions?

One Solution collect form web for “Performance Test et TCP tuning”

C'est un malheureux inconvénient de Windows. Lorsqu'un server Windows est submergé, il refuse activement les connections (répondant à un RST) plutôt que de ne pas y répondre (sans envoyer de SYN). Pour éviter que cela ne soit interprété comme un échec, les clients Windows réessayent généralement les connections (en envoyant un autre SYN), même lorsqu'ils sont activement refusés (réponds avec un RST).

Vous devriez réessayer la connection, même si elle est activement refusée. De toute évidence, si vous tentez plus de connections par seconde que le server peut gérer, ils ne peuvent pas tous réussir. La façon dont vous souhaitez gérer cette affaire dépend de vous.

La réponse courte est donc: qu'est-ce que vous voulez arriver si vous obtenez plus de tentatives de connection que le server peut gérer? Voulez-vous qu'ils passent vraiment, vraiment lentement? Ou voulez-vous qu'ils échouent? Si le premier, réessayez pour toujours, attendez plus longtime et plus longtime les tentatives intermédiaires. Si ce dernier, renoncez.

L'augmentation du carnet de commands aidera à éviter les courtes rafales de chargement de triggersr cette erreur. Mais si le taux de connection dépasse le taux que le server peut gérer, vous ne pouvez pas le faire fonctionner. Aucun nombre fini de connections sauvegardées ne fonctionnerait parce que le taux de connection dépasse le taux d'achèvement du travail. Donc, à un moment donné, vous devez commencer à échouer à less que les clients ne soient spécifiquement codés pour réessayer à jamais.

  • Créer un système de notification d'alerte pour les counturs de performance (logman, planificateur de tâches, events)
  • PowerShell? L'utilisez-vous? Pouvez-vous me montrer de l'administration de système cool que je peux faire avec ça?
  • SID dans Active Directory GPO
  • Problème avec le routing entre VM Hyper-V
  • Marche à suivre automatique pour le contrôleur de domaine
  • Ne peut pas recevoir de courrier électronique. Courrier électronique retardé. Problème avec MX?
  • Problème avec regsvr32 sur Windows Server 2008
  • Mapping Drive Error - Erreur système 1808
  • Meilleur MailServer pour Windows 2008 et intégration avec ASP.Net
  • Affichage de l'utilisation de RAM du cache de SQL?
  • Script de création Powershell AD Group
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.