J’utilise incorrectement HttpClient depuis des années, mais finalement le cauchemar est arrivé. Mon site web était instable et mes clients étaient très en colère ; avec une simple solution, les performances se sont grandement améliorées et l’instabilité a disparu.
En même temps, j’ai en fait amélioré les performances de mon application avec une utilisation plus efficace des sockets.
Les microservices peuvent être un problème difficile à gérer. À mesure que de nouveaux services sont ajoutés et que les applications monolithiques se décomposent, il y a de plus en plus de chemins de communication entre les services. Il existe de nombreuses options de communication, mais HTTP est une option très populaire. Si le microservice est construit en C# ou dans un langage .NET, il y a de fortes chances que vous utilisiez déjà HttpClient.
Le problème réside
L’instruction using est une caractéristique C# qui gère des objets à usage unique. Une fois le bloc d’utilisation terminé, l’objet à usage unique (dans ce cas HttpClient) sort du champ d’application et est éliminé. Appelez la méthode de gestion et éliminez les ressources utilisées. C’est un schéma très typique en .NET que nous utilisons pour tout, de la base de données à l’écrivain de flux. En fait, tout objet avec une ressource externe qui doit être nettoyée utilise cette interface IDisposable.
Et on ne peut pas vous en vouloir de vouloir l’envelopper dans l’usage. Premièrement, il est considéré comme une bonne pratique de le faire. En fait, la documentation officielle de Microsoft utilise :
En général, lorsqu’on utilise un objet IDisposable, il doit être déclaré et instancié dans l’instruction using (utilisation).
Mais HttpClient est différent. Bien qu’il implémente l’interface IDisposable, il s’agit en réalité d’un objet partagé. Cela signifie qu’en coulisses, elle est réentrante et sûre du fil. Vous devriez partager une instance d’HttpClient tout au long de la durée de vie de votre application, plutôt que de créer une nouvelle instance à chaque exécution. HttpClient, voyons pourquoi.
Regarde par toi-même
Voici un programme simple pour démontrer HttpClient :
Ceci sera adressé à http://aspnetmonsters.comOuvrez 10 requêtes et faites GET, nous imprimons simplement le code de statut, pour être sûrs que ça fonctionne. La sortie sera :
Attends, il y a autre chose !
Tout travail et tout est parfait pour le monde. Sauf que ce n’est pas le cas. Si nous sortons l’outil netstat et regardons le statut du socket sur la machine qui l’exécute, nous verrons :
C:\code\socket>NETSTAT.EXE
...
Proto Adresse locale État de l’adresse étrangère
TCP 10.211.55.6:12050 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12051 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12053 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12054 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12055 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12056 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12057 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12058 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12059 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12060 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12061 waws-prod-bay-017 :http TIME_WAIT
TCP 10.211.55.6:12062 waws-prod-bay-017 :http TIME_WAIT
TCP 127.0.0.1:1695 SIMONTIMMS742B :1696 ÉTABLI
...
Windows restera connecté dans cet état pendant 240 secondes (comme défini en définissant [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay]). Windows a une limite à la rapidité avec laquelle vous pouvez ouvrir un nouveau socket, donc si vous manquez de pools de connexions, vous pouvez voir une erreur comme celle-ci :
Impossible de se connecter au serveur distant
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Répare ça
Si nous partageons une instance d’HttpClient, nous pouvons réduire le gaspillage de sockets en les réutilisant :
Notez que pour toute l’application, nous n’avons qu’une seule instance partagée. Le client Http fonctionne toujours comme avant (en fait un peu plus rapide grâce à la réutilisation des sockets). Netstat n’affiche désormais que :
TCP 10.211.55.6:12254 waws-prod-bay-017 :http ÉTABLI
Ceci fait partie d’un graphique de notre outil de surveillance qui montre ce qui se passe après avoir déployé un nombre limité de preuves de correction sur un nombre restreint de microservices.
C’était dramatique. Si vous avez un quelconque type de charge, vous devez garder ces deux choses à l’esprit :
Faites en sorte que votre HttpClient soit statique.
Ne jetez pas ou ne regroupez pas votre utilisation à moins que vous ne recherchez explicitement un comportement spécifique (comme causer une défaillance de votre service). HttpClient
résumé
Le problème d’épuisement des douilles avec lequel nous luttions depuis des mois a disparu, et nos clients organisent une parade virtuelle. Je ne peux pas sous-estimer à quel point cette erreur est peu évidente. Au fil des années, nous avons l’habitude de gérer des objets implémentés, IDisposable, et de nombreux outils de refactorisation comme R# et CodeRush vous avertissent même si vous ne le faites pas. Dans ce cas, éliminer HttpClient est la mauvaise approche. HttpClient implémente IDisposable et encourage les mauvais comportements, ce qui est malheureux
Langue source:La connexion hyperlientérée est visible.
|
Publié sur 14/05/2022 17:11:56
|
|
|
|
Propriétaire|
Publié sur 14/05/2022 17:25:22
|
Publié sur 14/05/2022 22:35:22
|
