Verkeerd gebruiken van HttpClient kan je software kapot maken

Klein tuig · Geplaatst op 14-05-2022 17:11:56

Ik gebruik HttpClient al jaren verkeerd, maar uiteindelijk kwam de nachtmerrie. Mijn website was instabiel en mijn klanten waren erg boos, en met een simpele oplossing werd de prestatie sterk verbeterd en werd de instabiliteit geëlimineerd.

Tegelijkertijd heb ik de prestaties van mijn applicatie zelfs verbeterd door efficiënter socketgebruik te maken.

Microservices kunnen een lastig probleem zijn om mee om te gaan. Naarmate er meer diensten worden toegevoegd en monolithische applicaties worden ontleden, zijn er steeds meer communicatiepaden tussen services. Er zijn veel communicatiemogelijkheden, maar HTTP is een zeer populaire optie. Als de microservice in C# of een andere .NET-taal is gebouwd, is de kans groot dat je al HttpClient gebruikt.

Inloggen is zichtbaar.

Het probleem ligt

De using instructie is een C#-functie die eenmalige objecten behandelt. Zodra het gebruik van het blok voltooid is, is het eenmalige object (in dit geval HttpClient) buiten bereik en verwijderd. Roep de verwijdermethode en ruim alle gebruikte middelen op. Dit is een heel typisch patroon in .NET dat we gebruiken voor alles, van de database tot de flow writer. In feite gebruikt elk object met een externe bron die moet worden opgeschoond die IDISPOSABLE-interface.

En je kunt het niet kwalijk nemen dat je het in gebruik wilt wikkelen. Ten eerste wordt het als een goede praktijk beschouwd om dit te doen. In feite gebruikt Microsofts officiële documentatie het volgende:

In het algemeen moet een IDisposable-object worden gedeclareerd en geïnstantieerd in de using statement.

Ten tweede, alle code die je misschien hebt gezien...... Het begin van de HttpClient vertelt je dat je het using statement-blok moet gebruiken, inclusief de nieuwste documentatie ASP.NET de site zelf. Hetzelfde wordt gezegd in het artikel op het internet.

Maar HttpClient is anders. Hoewel het de IDisposable-interface implementeert, is het eigenlijk een gedeeld object. Dit betekent dat het achter de schermen een reentrant en draadveilig is. Je moet een HttpClient-instantie delen gedurende de levensduur van je applicatie, in plaats van voor elke uitvoering een nieuwe instantie aan te maken. HttpClient, laten we eens kijken waarom.

Kijk zelf maar

Hier is een eenvoudig programma om HttpClient te demonstreren:

Inloggen is zichtbaar.

Dit zal worden gericht aan http://aspnetmonsters.comOpen 10 verzoeken en doe GET, we printen gewoon de statuscode uit, zodat we weten dat het werkt. De output zal zijn:

Inloggen is zichtbaar.

Wacht, er is meer!

Al het werk en alles is goed voor de wereld. Behalve dat het dat niet is. Als we de netstat-tool eruit halen en de socketstatus van de machine bekijken die het draait, zien we:

C:\code\socket>NETSTAT.EXE
...
  Proto Lokaal Adres Buitenlands Adres Staat
  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 OPGERICHT
...

Nou, het is vreemd...... De applicatie is uitgeschakeld, maar er zijn nog steeds een aantal van deze verbindingen open naar de Azure-machine die de ASP.NET Monsters-website host. Ze zitten erinTIME_WAITstatus, wat betekent dat de verbinding aan één kant (de onze) is gesloten, maar we wachten nog steeds af of er nog andere pakketten binnenkomen omdat ze mogelijk ergens vertraagd zijn op het netwerk. Hier is een diagram van de TCP/IP-status:

Windows blijft in deze toestand 240 seconden verbonden (zoals ingesteld door [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay]) in te stellen). Windows heeft een limiet aan hoe snel je een nieuwe socket kunt openen, dus als je geen verbindingspools meer hebt, kun je een fout als deze zien:

Kan geen verbinding maken met de externe server
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Als je ernaar zoekt op Google, krijg je slecht advies over het verminderen van verbindingstime-outs. Sterker nog, wanneer het correct draait op een server met HttpClient of een vergelijkbaar opgebouwde applicatie, kan het verminderen van time-outs leiden tot andere nadelige gevolgen. We moeten begrijpen wat "juist" betekent en het onderliggende probleem oplossen, niet knutselen aan machineniveau-variabelen.

Los het op

Als we een instantie van HttpClient delen, kunnen we socket waste verminderen door ze opnieuw te gebruiken:

Inloggen is zichtbaar.

Let op dat we voor de hele applicatie slechts één gedeelde instantie hebben. HttpClient werkt nog steeds zoals voorheen (eigenlijk iets sneller door hergebruik van sockets). Netstat toont nu alleen nog:

TCP 10.211.55.6:12254 waws-prod-bay-017:http OPGERICHT

In een productiescenario ligt mijn socket-aantal gemiddeld rond de 4000 en piekt het op meer dan 5000, waardoor de beschikbare resources op de server effectief worden uitgeput en de service crasht. Na de doorvoering van de wijziging daalde het aantal gebruikte sockets van gemiddeld meer dan 4000 tot consequent minder dan 400, meestal rond de 100.

Dit maakt deel uit van een grafiek van onze monitoringtool die laat zien wat er gebeurt nadat we een beperkt aantal fix proofs hebben uitgerold op een select aantal microservices.

Het was dramatisch. Als je een bepaalde belasting hebt, moet je deze twee dingen in gedachten houden:

Maak je HttpClient statisch.
Gooi je gebruik niet weg of verpak je niet, tenzij je expliciet op zoek bent naar een specifiek gedrag (zoals het veroorzaken van een storing van je dienst). HttpClient

samenvatting

Het probleem met de socketuitputting waar we al maanden mee worstelen is verdwenen, en onze klanten hebben een virtuele parade. Ik kan niet onderschatten hoe onduidelijk deze fout is. Door de jaren heen zijn we gewend geraakt aan het werken met geïmplementeerde objecten, IDisposable, en veel refactoringtools zoals R# en CodeRush waarschuwen je zelfs als je dat niet doet. In dit geval is het verwijderen van HttpClient de verkeerde aanpak. HttpClient implementeert IDisposable en moedigt slecht gedrag aan is jammer

Origineel:De hyperlink-login is zichtbaar.

Klein tuig · Geplaatst op 14-05-2022 17:25:22

TCP TIME_WAIT is een normale TCP-protocoloperatie, wat betekent dat nadat de laatste FIN-ACK is doorgegeven, de client wacht tot de dubbele maximale levensduur (MSL) is verstreken om ervoor te zorgen dat het externe TCP een bevestiging ontvangt van zijn verzoek om verbinding te beëindigen. Standaard is MSL 2 minuten. Je kunt tot 4 minuten in TIME_WAIT blijven, bekend als twee MSL's.

https://docs.microsoft.com/en-us ... t-from-netstat.html

vliegende vis · Geplaatst op 14-05-2022 22:35:22

Leer leren

Johnyoung · Geplaatst op 19-05-2022 09:39:05

Het is allemaal Chinees, maar ik kan het niet begrijpen als het in zinnen is verbonden

Klein tuig · Geplaatst op 06-11-2023 07:16:05

[Bron] Verkeerd gebruiken van HttpClient kan je software kapot maken

Gerelateerde berichten

Secties bekeken