He estado usando HttpClient incorrectamente durante años, pero al final llegó la pesadilla. Mi web era inestable y mis clientes estaban muy enfadados, y con una solución sencilla, el rendimiento mejoró mucho y la inestabilidad se eliminó.
Al mismo tiempo, de hecho mejoré el rendimiento de mi aplicación con un uso más eficiente del socket.
Los microservicios pueden ser un problema difícil de resolver. A medida que se añaden más servicios y se descomponen aplicaciones monolíticas, tienden a haber cada vez más vías de comunicación entre servicios. Hay muchas opciones de comunicación, pero HTTP es una opción muy popular. Si el microservicio está construido en C# o en cualquier lenguaje .NET, lo más probable es que ya estés usando HttpClient.
El problema radica
La sentencia using es una característica de C# que maneja objetos de un solo uso. Una vez que el bloque de uso está completo, el objeto de un solo uso (en este caso HttpClient) queda fuera de alcance y se elimina. Llama al método de eliminación y limpia cualquier recurso que se esté utilizando. Este es un patrón muy típico en .NET que usamos para todo, desde la base de datos hasta el escribador de flujos. De hecho, cualquier objeto con un recurso externo que deba limpiarse utiliza esa interfaz IDisposable.
Y no se te puede culpar por querer envolverlo en el consumo. En primer lugar, se considera una buena práctica hacerlo. De hecho, la documentación oficial de Microsoft utiliza:
En general, al usar un objeto IDisposable, debe declararse e instanciarse en la sentencia usando.
Pero HttpClient es diferente. Aunque implementa la interfaz IDisposable, en realidad es un objeto compartido. Esto significa que, tras bambalinas, es reentrante y seguro de hilo. Deberías compartir una instancia de HttpClient a lo largo de la vida útil de tu aplicación, en lugar de crear una nueva instancia para cada ejecución. HttpClient, veamos por qué.
Compruébalo tú mismo
Aquí tienes un programa sencillo para demostrar HttpClient:
Esto se dirigirá a http://aspnetmonsters.comAbre 10 solicitudes y haz GET, solo imprimimos el código de estado para saber que funciona. La salida será:
¡Espera, hay más!
Todo trabajo y todo es lo correcto para el mundo. Excepto que no lo es. Si sacamos la herramienta netstat y miramos el estado del socket en la máquina que la ejecuta, veremos:
C:\code\socket>NETSTAT.EXE
...
Dirección Local Proto Estado de Dirección Extranjera
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 ESTABLECIDO
...
Windows permanecerá conectado en este estado durante 240 segundos (según se establece configurando [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay]). Windows tiene un límite en la rapidez con la que puedes abrir un nuevo socket, así que si te quedas sin pools de conexión, puede que veas un error como este:
No se puede conectar al servidor remoto
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Arréglalo
Si compartimos una instancia de HttpClient, podemos reducir el desperdicio de sockets reutilizándolos:
Ten en cuenta que para toda la aplicación solo tenemos una instancia compartida. HttpClient sigue funcionando igual que antes (de hecho, un poco más rápido por la reutilización de sockets). Netstat ahora solo muestra:
TCP 10.211.55.6:12254 waws-prod-bay-017:http ESTABLECIDO
Esto forma parte de un gráfico de nuestra herramienta de monitorización que muestra lo que ocurre después de desplegar un número limitado de pruebas de corrección en un número selecto de microservicios.
Fue dramático. Si tienes algún tipo de carga, debes tener en cuenta estas dos cosas:
Haz que tu HttpClient sea estático.
No descartes ni empaquetes tu uso a menos que busques explícitamente un comportamiento específico (como provocar que tu servicio falle). HttpClient
resumen
El problema de agotamiento de los sockets con el que llevábamos meses lidiando ha desaparecido, y nuestros clientes tienen un desfile virtual. No puedo subestimar lo poco obvio que es este error. A lo largo de los años, hemos estado acostumbrados a lidiar con objetos implementados, IDisposable, y muchas herramientas de refactorización como R# y CodeRush realmente te avisan si no lo haces. En este caso, eliminar HttpClient es el enfoque equivocado. HttpClient implementa IDisposable y fomenta un mal comportamiento es desafortunado
Texto original en:El inicio de sesión del hipervínculo es visible.
|
Publicado en 14/5/2022 17:11:56
|
|
|
|
Propietario|
Publicado en 14/5/2022 17:25:22
|
Publicado en 14/5/2022 22:35:22
|
