Медленное подключение к базе данных из Azure Web Application
Я разработал веб-приложение стандартное веб-приложение, чтобы пользователи могли отображать и обновлять набор данных из базы данных SQL.
В веб-приложении используется клиентская сторона AngularJS, которая взаимодействует с веб-сервером с помощью вызовов MVC Web API для извлечения и обновления данных в базе данных. Код на стороне сервера написан на C # с использованием .NET 4.5 и использует Entity Framework v6.0 для доступа к базе данных.
Веб-приложение размещено в веб-приложении Azure. База данных – это база данных Azure SQL.
- Задержка между двумя Azure VM
- У подписки нет разрешений для регистрации поставщика ресурсов Microsoft.Sql
- Обновлять изменения в локальном SQL-сервере db до Sql Azure db немедленно?
- SQL Server с Oracle SQL Developer 4.1 - невозможно просмотреть таблицы
- SQL-хранилище данных: неправильный синтаксис рядом с «OFFSET»
Проблема в том, что когда приложение не использовалось в течение 10-15 минут, оно снова используется, первый поиск данных часто занимает более 10 секунд, чтобы вернуться в браузер. После этого производительность будет прекрасной до следующего раза, когда приложение останется неиспользованным.
Я поместил трассировку в приложение, и мы видим, что задержка возникает, когда соединение открывается. Фактический запрос в базе данных работает под второй секундой.
Я заметил, что с разными настройками хостинга я получаю разные результаты. В частности, хостинг в доме и указание на базу данных Azure не сталкиваются ни с чем рядом с теми же задержками.
Я изменил одну из подпрограмм, чтобы использовать ADO.NET вместо Entity Framework и изменил трассировку, чтобы попытаться сузить ее дальше.
Я вижу следующее:
ConnectionStringSettings ADOcnxstring = ConfigurationManager.ConnectionStrings["DevFEConnectAdo"]; DbConnection ADOconnection = new SqlConnection(ADOcnxstring.ConnectionString);
Задержка здесь (до того, как SQL был определен!
и затем я создаю команду и делаю DataReader и т. д.
DbCommand ADOcommand = ADOconnection.CreateCommand(); : etc
Таким образом, задержка заключается в открытии соединения с базой данных.
Строка подключения стандартная:
<add name="DevFEConnectAdo" connectionString="data source=feeunsqldevfeconnect.database.windows.net;initial catalog=feeunsqldbdevfeconnect;persist security info=True;user id=??? @???;password=???;multipleactiveresultsets=True"></add>
- Попытка развертывания базы данных Asp.Net Memebership для SQL Azure
- Соединение Azure AWS Db
- tSQL для настройки пользователя с разрешением разрешения просмотра на SQL Azure
- Невозможно включить полнотекстовый поиск в базе данных Azure SQL V12
- Установка содержимого контейнера blob в качестве диска в виртуальной машине
- Логический метод использования SSIS для преобразования данных и их загрузки в Azure Data Warehouse
- Строка подключения для SQL Server на Azure VM
- Как остановить (освободить) SQL-сервер в Azure?
15 минут слишком короткие, чтобы ваше приложение было переработано (как было предложено CSharpRocks). Я не думаю, что это проблема.
Задержка заключается в том, что при первом вызове после таймаута простоя устанавливается новое соединение Db. Обычно, если соединение неактивно в течение 4-10 минут, оно будет закрыто. Если задан минимальный размер пула, эти соединения будут поддерживаться в живых даже после истечения времени ожидания.
Попробуйте использовать эту строку подключения (отрегулируйте минимальный размер пула в соответствии с вашими потребностями)
<add name="DevFEConnectAdo" connectionString="data source=feeunsqldevfeconnect.database.windows.net;initial catalog=feeunsqldbdevfeconnect;persist security info=True;user id=??? @???;password=???;multipleactiveresultsets=True;Min Pool Size=3;Load Balance Timeout=180;"></add>
Дополнительная информация Почему нам нужно установить размер Min pool в ConnectionString
Список свойств подключения SQL – документация
Веб-приложения перерабатываются через несколько минут бездействия. Попробуйте включить параметр Always On, расположенный в настройках / настройках приложения на портале, чтобы узнать, помогает ли это в вашей проблеме.
По прошествии некоторого времени это в конечном итоге было разрешено с помощью поддержки Microsoft Azure.
Деталь, о которой я забыл, заключалась в том, что мое веб-приложение фактически указывало на 2 базы данных – 1 базу данных приложения Azure SQL, у меня была проблема с задержкой – «хранилище данных», которое мы имели на виртуальной машине Azure
Из-за репликации между внутренними серверами баз данных и «хранилищем данных» виртуальная машина и веб-приложение находились в виртуальной сети Azure.
Проблема в том, что могут возникнуть проблемы с сетью, если веб-приложение внутри виртуальной сети хочет поговорить с базами данных Azure SQL (которые не могут находиться в виртуальной сети).
Мое решение было
- настроить конечную точку на виртуальном сервере хранилища данных,
- вывести веб-приложение из виртуальной сети и указать его на виртуальный сервер с помощью конечной точки
В этот момент все задержки ушли, и я мог снять настройки MinPool Size (и Timeout, которые я позже обнаружил, ничего не сделал).