c# - targeting - Actualización de.NET framework que resulta en tiempos de espera de SQL
net framework sdk (1)
No he experimentado esto, pero el enlace https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.0-4.7.1 indica un cambio en la agrupación de conexiones SQL, donde Ahora reintenta conexiones rotas por mucho más tiempo. El enlace también proporciona una configuración para omitir el nuevo comportamiento;
ConnectRetryCount = 0
¿Es posible que las conexiones en el grupo permanezcan vivas mucho más tiempo que antes como un efecto secundario o una característica prevista de este cambio de comportamiento y, por lo tanto, obstruyan su grupo de conexiones con ''conexiones muertas pero que vuelvan a intentar'' mientras que anteriormente habrían muerto?
Es un poco especulativo; pero podría llevarte por el camino correcto.
Tenemos una aplicación que apunta a .NET 4.5.1, y esto se ha mantenido sin cambios.
Sin embargo, cuando actualizamos el marco .NET en el servidor de 4.5.1 -> 4.7.1, comenzamos a experimentar los tiempos de espera de SQL varias horas después (el objetivo de la aplicación se mantuvo en 4.5.1).
"Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached."
Otros servidores que tenían el mismo tratamiento también produjeron el problema, por lo que buscamos un cambio importante en .NET y encontramos este artículo: https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/
Ese artículo cita un tipo de excepción diferente, pero podría estar algo relacionado. Sin embargo, me sorprendería si nuestra búsqueda de DNS tomara más de 500 ms. También esperaría ver muchos más casos de esta configuración de cadena de conexión informada y utilizada.
Nuestra aplicación es de alto tráfico, pero confiamos en que no estamos perdiendo conexiones ya que esto nunca ha sido un problema durante años hasta que actualizamos el marco .NET.
Vamos a intentar aplicar esta solución (y esperar> 24 horas para ver los resultados), pero ¿hay algo más que podamos haber pasado por alto? No estamos seguros de que esta sea la solución.
EDITAR: Incluso después de revertir .NET a 4.5.1 y reiniciar todos los servidores, todavía estamos viendo el problema. Nada más ha cambiado en el código base, pero aún tenemos que revertir un cambio en el registro que habilitó ''SchUseStrongCrypto'', ¿si eso podría ser la causa?