• Jobs
  • About Us
  • Jobs
    • Home
    • Jobs
    • Courses and challenges
  • Businesses
    • Home
    • Post vacancy
    • Our process
    • Pricing
    • Assessments
    • Payroll
    • Blog
    • Sales
    • Salary Calculator

0

724
Views
Cómo evitar que se agote el tiempo de espera de las conexiones HTTP salientes

Fondo:

Actualmente estoy hospedando una aplicación ASP.NET en Azure con las siguientes especificaciones:

  • ASP .Net Núcleo 2.2
  • Uso de Flurl para solicitudes HTTP
  • Servidor web Kestrel
  • Docker (Linux: tiempo de ejecución mcr.microsoft.com/dotnet/core/aspnet:2.2)
  • Azure App Service en plan de servicio de aplicaciones de nivel P2V2

Tengo un par de trabajos en segundo plano que se ejecutan en el servicio que realiza muchas llamadas HTTP salientes a un servicio de terceros.

Tema:

Con una carga pequeña (aproximadamente 1 llamada cada 10 segundos), todas las solicitudes se completan en menos de un segundo sin ningún problema. El problema que tengo es que bajo una carga pesada, cuando el servicio puede realizar hasta 3/4 llamadas en un lapso de 10 segundos, algunas de las solicitudes se agotarán aleatoriamente y generarán una excepción. Cuando estaba usando RestSharp, la excepción decía "Se agotó el tiempo de espera de la operación". Ahora que estoy usando Flurl, la excepción dice "Se agotó el tiempo de espera de la llamada".

Aquí está el truco: si ejecuto el mismo trabajo desde mi computadora portátil con Windows 10/Visual Studios 2017, este problema NO ocurre. Esto me lleva a creer que estoy llegando a algún límite o me estoy quedando sin algún recurso en mi entorno alojado. No está claro si eso está relacionado con la conexión/enchufe o el hilo.

Cosas que he probado:

  • Asegúrese de que todas las rutas de código a la solicitud utilicen async/await para evitar bloqueos
  • Asegúrese de que Kestrel Defaults permita conexiones ilimitadas (lo hace de forma predeterminada)
  • Asegúrese de que los límites de conexión predeterminados de Dockers sean suficientes (2000 por defecto, más que suficiente)
  • Configurar los ajustes de ServicePointManager para los límites de conexión

Aquí está el código en mi startup.cs que estoy usando actualmente para tratar de prevenir este problema:

 public class Startup { public Startup(IHostingEnvironment hostingEnvironment) { ... // ServicePointManager setup ServicePointManager.UseNagleAlgorithm = false; ServicePointManager.Expect100Continue = false; ServicePointManager.DefaultConnectionLimit = int.MaxValue; ServicePointManager.EnableDnsRoundRobin = true; ServicePointManager.ReusePort = true; // Set Service point timeouts var sp = ServicePointManager.FindServicePoint(new Uri("https://placeholder.thirdparty.com")); sp.ConnectionLeaseTimeout = 15 * 1000; // 15 seconds FlurlHttp.ConfigureClient("https://placeholder.thirdparty.com", cli => cli.Settings.ConnectionLeaseTimeout = new TimeSpan(0, 0, 15)); } }

¿Alguien más se ha encontrado con un problema similar a este? Estoy abierto a cualquier sugerencia sobre cómo depurar mejor esta situación o posibles métodos para corregir el problema. Estoy completamente perdido después de investigar esto durante varios días.

Gracias de antemano.

over 3 years ago · Santiago Trujillo
1 answers
Answer question

0

Tuve problemas similares. Eche un vistazo a Asp.net Core HttpClient tiene muchas conexiones TIME_WAIT o CLOSE_WAIT . La depuración a través de netstat me ayudó a identificar el problema. Como una posible solución. Le sugiero que use IHttpClientFactory . Puede obtener más información en https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-2.2 Debería ser bastante fácil de usar, como se describe en Vida útil del cliente Flurl en ASP .Net Core 2.1 y IHttpClientFactory

over 3 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Our process Sales
Legal
Terms and conditions Privacy policy
© 2025 PeakU Inc. All Rights Reserved.

Andres GPT

Show me some job opportunities
There's an error!