¿Cuál es la sobrecarga de crear un nuevo HttpClient por llamada en un cliente WebAPI?

Si quieres que tu aplicación se amplíe, ¡la diferencia es ENORME! Dependiendo de la carga, verá números de rendimiento muy diferentes. Como menciona Darrel Miller, el HttpClient fue diseñado para ser reutilizado a través de solicitudes. Esto fue confirmado por los chicos del equipo de BCL que lo escribieron.

Un proyecto reciente que tuve fue ayudar a un minorista de computadoras en línea muy grande y conocido a escalar el tráfico del Viernes Negro/feriado para algunos sistemas nuevos. Nos encontramos con algunos problemas de rendimiento en torno a la uso de HttpClient. Dado que implementa IDisposable, los desarrolladores hicieron lo que normalmente haría al crear una instancia y colocarla dentro de una instrucción using(). Una vez que comenzamos a probar la carga, la aplicación puso de rodillas al servidor, sí, el servidor no solo la aplicación. La razón es que cada instancia de HttpClient abre un puerto en el servidor. Debido a la finalización no determinista de GC y el hecho de que está trabajando con recursos informáticos que abarcan múltiples capas OSI, cerrar los puertos de red puede llevar un tiempo. De hecho, el propio sistema operativo Windows puede tardar hasta 20 segundos en cerrar un puerto (por Microsoft). Estábamos abriendo puertos más rápido de lo que podían ser cerrados - agotamiento del puerto del servidor que martilló la CPU al 100%. Mi solución fue cambiar el HttpClient a una instancia estática que resolvía el problema. Sí, es un recurso desechable, pero cualquier sobrecarga es ampliamente compensada por la diferencia en el rendimiento. Te animo a hacer algunas pruebas de carga para ver cómo tu aplicación comportar.

También puede consultar la página de guía de WebAPI para la documentación y el ejemplo en https://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client

Presta especial atención a esta llamada:

HttpClient está destinado a ser instanciado una vez y reutilizado durante toda la vida de una aplicación. Especialmente en aplicaciones de servidor, la creación de una nueva instancia HttpClient para cada solicitud agotará el número de sockets disponibles bajo cargas pesadas. Esto dará lugar a errores SocketException.

Si encuentra que necesita usar un HttpClient estático con diferentes encabezados, dirección base, etc. lo que tendrá que hacer es crear el HttpRequestMessage manualmente y establecer esos valores en el HttpRequestMessage. A continuación, utilice el HttpClient:SendAsync(HttpRequestMessage requestMessage, ...)

Como dicen las otras respuestas, HttpClient está destinado a ser reutilizado. Sin embargo, reutilizar una única instancia HttpClient en una aplicación multihilo significa que no puede cambiar los valores de sus propiedades con estado, como BaseAddress y DefaultRequestHeaders (por lo que solo puede usarlos si son constantes en toda la aplicación).

Un enfoque para sortear esta limitación es envolver HttpClient con una clase que duplique todos los métodos HttpClient que necesita (GetAsync, PostAsync etc) y los delega a un singleton HttpClient. Sin embargo, eso es bastante tedioso (necesitará envolver los métodos de extensión también), y afortunadamente hay otra forma: seguir creando nuevas instancias HttpClient, pero reutilizar el HttpClientHandler subyacente. Solo asegúrese de no deshacerse del controlador:

HttpClientHandler _sharedHandler = new HttpClientHandler(); //never dispose this
HttpClient GetClient(string token)
{
    //client code can dispose these HttpClient instances
    return new HttpClient(_sharedHandler, disposeHandler: false)         
    {
       DefaultRequestHeaders = 
       {
            Authorization = new AuthenticationHeaderValue("Bearer", token) 
       } 
    };
}

Relacionado con sitios web de alto volumen pero no directamente con HttpClient. Tenemos el fragmento de código a continuación en todos nuestros servicios.

// number of milliseconds after which an active System.Net.ServicePoint connection is closed.
const int DefaultConnectionLeaseTimeout = 60000;

ServicePoint sp = ServicePointManager.FindServicePoint(new Uri("http://<yourServiceUrlHere>"));
sp.ConnectionLeaseTimeout = DefaultConnectionLeaseTimeout;

Desde https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(System.Net.ServicePoint.ConnectionLeaseTimeout);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.5.2);k(DevLang-csharp)&rd=true

"Puede usar esta propiedad para asegurarse de que las conexiones activas de un objeto ServicePoint no permanezcan abiertas indefinidamente. Esta propiedad está diseñada para escenarios en los que las conexiones se deben eliminar y restablecer periódicamente, como escenarios de equilibrio de carga.

De forma predeterminada, cuando KeepAlive es true para una solicitud, la propiedad maxIdleTime establece el tiempo de espera para cerrar conexiones de ServicePoint debido a la inactividad. Si el ServicePoint tiene conexiones activas, maxIdleTime no tiene efecto y las conexiones permanecen abiertas indefinidamente.

Cuando la propiedad ConnectionLeaseTimeout se establece en un valor distinto de -1, y después de que transcurra el tiempo especificado, una conexión de ServicePoint activa se cierra después de atender una solicitud configurando KeepAlive en false en esa solicitud. Establecer este valor afecta a todas las conexiones administradas por el objeto ServicePoint."

Cuando tiene servicios detrás de una CDN u otro endpoint que desea conmutar por error, esta configuración ayuda a las personas que llaman a seguirle a su nuevo destino. En este ejemplo, 60 segundos después de una conmutación por error, todas las personas que llaman deben volver a conectarse al nuevo punto final. Se requiere que conozca sus servicios dependientes (aquellos servicios a los que llama) y sus puntos finales.

Es posible que también desee hacer referencia a esta entrada de blog de Simon Timms: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong /

Pero HttpClient es diferente. Aunque implementa la interfaz IDisposable en realidad es un objeto compartido. Esto significa que bajo las cubiertas es reentrante) y hilo seguro. En lugar de crear una nueva instancia de HttpClient para cada ejecución, debe compartir una sola instancia de HttpClient durante toda la vida útil de la aplicación. Veamos por qué.