Функции Azure static SqlConnection - правильный масштаб?

Question

Я использую функции Azure с триггерами очереди для части нашей рабочей нагрузки.Специальная функция запрашивает базу данных, и это создает проблемы с масштабированием, так как большое количество одновременных проверок экземпляров функции, проверяющих db, приводит к тому, что максимально допустимое количество соединений с базой данных Azrue постоянно поражается.

В этой статье https://docs.microsoft.com/en-us/azure/azure-functions/manage-connections HttpClient указан как один из тех ресурсов, которые следует сделать статическими.Должен ли доступ к базе данных также быть статическим со статическим SqlConnection для решения этой проблемы, или это вызвало бы некоторые другие проблемы при сохранении объекта постоянного соединения?

Answer 1

Вы можете использовать параметры конфигурации в host.json , чтобы контролировать уровень параллелизма, который выполняются ваши функции для каждого экземпляра, и параметр max scaleout , чтобы контролировать, сколько экземпляров вы масштабируетек.Это позволит вам контролировать общую нагрузку на вашу базу данных.

Answer 2

Для будущих читателей, документация была обновлена ​​с некоторыми сведениями о соединении SQL , заявив:

Ваш код функции может использовать поставщик данных .NET Framework для SQL Server.(SqlClient) для подключения к реляционной базе данных SQL.Это также основной поставщик платформ данных, основанных на ADO.NET, таких как Entity Framework.В отличие от соединений HttpClient и DocumentClient, ADO.NET по умолчанию реализует пул соединений.Тем не менее, поскольку у вас все еще не хватает соединений, вам следует оптимизировать соединения с базой данных.Для получения дополнительной информации см. Пул соединений с сервером SQL (ADO.NET).

Итак, , как уже упоминал Дэвид Браун , не следует делать SqlConnection статичным.

Answer 3

Если доступ к базе данных также делается статическим со статическим SqlConnection

Определенно нет.Каждый вызов функции должен открывать новый SqlConnection с той же строкой соединения в блоке using.Не совсем понятно, сколько одновременных вызовов функций будет выполнять среда выполнения для одного экземпляра вашего приложения.Но если оно больше 1, то одноэлементное SqlConnection - это плохо.

Интересно, какой именно предел вы используете в базе данных SQL, лимит соединения или лимит одновременных запросов?В любом случае я немного удивлен (не эксперт по функциям), что вы получаете столько одновременных вызовов функций, так что может произойти что-то еще.Как будто вы пропускаете SqlConnections.

Но, читая документы по функциям, я предполагаю, что время выполнения функций масштабируется путем запуска нескольких экземпляров приложения-функции.Ваше приложение .NET может масштабироваться в одном процессе, но, очевидно, это не так, как работает функция.Каждый экземпляр вашего приложения Functions имеет свой собственный ConnectionPool для SQL Server, и по умолчанию каждый ConnectionPool может иметь 100 соединений.

Возможно, если вы резко ограничите максимальный размер пула в строке подключения, не будет так много открытых соединений.Когда вы нажмете Максимальный размер пула, новые вызовы SqlConnection.Open () будут блокироваться на срок до 30 секунд, ожидая доступности пула SqlConnection.Таким образом, это не только ограничивает использование соединения для каждого экземпляра вашего приложения, но и снижает пропускную способность под нагрузкой.