Время получения нового соединения из пула соединений в приложении ASP.Net. Мне нужны предложения по смягчению

Question

Мы получаем следующую ошибку в определенной базе данных иногда при умеренной загрузке.

"System.InvalidOperationException: Timeout expired. Период ожидания истек до получения соединения из пула. Это могло произойти, потому что все соединения в пуле использовались и был достигнут максимальный размер пула."

Я прочесал код, и мы закрываем соединения в блоках finally, как мы должны, за исключением нескольких случаев, которые, как мы установили, вызываются очень редко. Мы исправим эти фрагменты кода в нашем следующем выпуске, но для решения текущей производственной проблемы я предлагаю увеличить максимальный размер пула до 300. Максимальное число одновременных пользователей, с которыми мы сейчас сталкиваемся, составляет около 110, что, очевидно, превышает размер пула по умолчанию ( 100).

Я также предлагаю убедиться, что все строки подключения к конкретному экземпляру SQL Server идентичны, чтобы избежать ненужного создания нескольких пулов подключений. Я надеюсь, что мы можем использовать оператор USE [Database] перед нашими фактическими запросами SQL, когда нам нужно переключить базы данных в одном экземпляре SQL Server.

У вас, ребята, есть какие-нибудь идеи, указатели, предложения или ошибки, за которыми стоит следить?

Answer 1

Необходимо устранить утечки соединения . Если причиной истощения пула является утечка, увеличение его до 300 просто задержит неизбежное. Если вы пропускаете одно соединение за 10000 вызовов (т. Е. «Очень редко»), и у вас есть 110 одновременных запросов, скажем, за 5 секунд вызова, вы пропускаете со скоростью около одного соединения каждые 8 ​​минут, что приводит к истощению пула в сети. 13 часов Хотя тайм-ауты начнут появляться намного раньше, так как доступный размер пула сократится.

Если у вас есть веские доказательства того, что причина не в утечках, а в том, что количество вызовов зависит от размера пула, вам следует увеличить размер пула. Независимо от размера пула, который вы решите использовать, если ваши запросы требуют соединения 1: 1 для всей продолжительности запросов, вам нужно ограничить / поставить в очередь HTTP, чтобы он не превышал размер пула. Если нет, вы все равно можете столкнуться с шипами, которые истощают бассейн.

Также вы можете рассмотреть возможность использования более гибкой фабрики соединений, которая повторяет попытки и пытается установить соединение без пула, если пул очищается. Конечно, это идет рука об руку с моим предыдущим замечанием о том, что если вы откалибруете максимальное число принимаемых HTTP-запросов, чтобы соответствовать размеру пула, то пул не может быть исчерпан (если не произойдет утечка, вернитесь к исходной точке). Я бы не рекомендовал это, хотя, я думаю, гораздо лучше ставить запросы в очередь на территории http.sys, чем на территории выделения ресурсов приложения (т. Е. Ограничивать максимально допустимые HTTP-вызовы).

И, наконец, что не менее важно, уменьшите продолжительность каждого звонка. Если ваш вызов занимает в среднем 5 секунд, то вы видите одновременно 110 соединений со скоростью всего 22 запроса в секунду. Если вы сократите продолжительность вызова, устранив узкие места SQL до 1 секунды, вы сможете обслуживать 110 запросов в секунду для достижения того же ограничения ресурсов (110 одновременных запросов), то есть увеличение трафика в 5 раз. Самым большим виновником обычно является сканирование таблицы, убедитесь, что все ваши запросы используют разумный SQL и имеют оптимальный путь доступа к данным. Как говорит Дэвид, SQL Profiler - ваш друг.

Вы также можете использовать SqlConnection.ChangeDatabase для изменения базы данных.