c# - условием - установить net framework



Обновление.NET Framework, приводящее к тайм-аутам SQL (1)

Я не испытывал этого, но ссылка https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.0-4.7.1 указывает на изменение пула соединений SQL, где оно теперь пытается разорвать связь гораздо дольше. Ссылка также предоставляет параметр для обхода нового поведения;

 ConnectRetryCount = 0

Возможно ли, что соединения в пуле теперь остаются живыми намного дольше, чем раньше, как побочный эффект или предполагаемая особенность этого изменения поведения, и поэтому засоряют ваш пул соединений «мертвыми, но повторными соединениями», тогда как раньше они бы умерли?

Это немного умозрительно; но может привести вас на правильный путь.

У нас есть приложение, предназначенное для .NET 4.5.1, и оно осталось без изменений.

Однако когда мы обновили .NET Framework на сервере с 4.5.1 -> 4.7.1, через несколько часов после этого мы начали испытывать таймауты SQL (цель приложения осталась на уровне 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."

Эта проблема возникла и на других серверах, которые имели такую ​​же обработку, поэтому мы искали серьезные изменения в .NET и нашли эту статью: https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/

Эта статья цитирует другой тип исключения, но может быть несколько связанным. Однако я был бы ошеломлен, если бы наш поиск DNS занял больше 500 мс. Кроме того, я ожидаю увидеть гораздо больше случаев, когда сообщается и используется эта конфигурация строки подключения.

Наше приложение имеет высокий трафик, но мы уверены, что не будем пропускать соединения, так как это никогда не было проблемой в течение многих лет, пока мы не обновили .NET Framework.

Мы собираемся попробовать применить это исправление (и подождать> 24 часа, чтобы увидеть результаты), но есть ли что-то еще, что мы могли бы пропустить? Мы не уверены, что это решение.

РЕДАКТИРОВАТЬ: Даже после отката .NET до 4.5.1 и перезапуска всех серверов, мы все еще видим проблему. Ничего другого не изменилось в кодовой базе, но нам еще предстоит откатить изменение реестра, которое включило SchUseStrongCrypto - может ли это быть причиной?





connection-pooling