База данных Azure, EF, проблемы с тайм-аутом

Question

Я завладел существующим веб-сайтом MVC, который использует инфраструктуру сущностей и Hangfire, размещен в Azure и использует базу данных Azure.Время от времени веб-сайт отключается.

Я новичок в портале Azure, инфраструктуре сущностей и Hangfire.

Если увеличить DTU, это устранит проблемы тайм-аута?

Я ищу способы, как диагностировать, почему время ожидания веб-сайта.Я добавил ведение журнала ошибок, используя elmah, и проверил hangfire, но это не дает мне никакой дополнительной информации.

Есть ли на портале Azure что-нибудь, что может помочь?

Answer 1

SQL Azure - это немного другой зверь.Он не имеет производительности выделенной БД по требованию, если вы не готовы потратить на это серьезные $$.И даже тогда ...

EF, когда написано хорошо, может хорошо работать.При плохом написании это может быть собакой, и эти проблемы усугубляются на платформе, такой как SQL Azure.

Прежде всего, убедитесь, что ваши EF-контексты настроены на использование стратегии выполнения, подходящей для Azure: https://docs.microsoft.com/en-us/ef/ef6/fundamentals/connection-resiliency/retry-logic

Следующим шагом будет посмотреть, какие виды трассировки SQL можно запустить в Azure.Отслеживание важно, чтобы увидеть, что EF делает за кулисами.Я не знаком с инструментами, доступными для Azure, в моем случае мой опыт работы с Azure заключался в запуске SQL Server на виртуальных машинах, потому что SQL Azure был слишком незрелым, не совместимым с HIPAA в то время и дорогим для оценок DTU, которые мы смогли получить.В худшем случае, вы можете восстановить резервную копию базы данных в экземпляр SQL Server и временно указать копию среды вашего приложения для выполнения сценариев общего использования?Используя трассировку SQL, вы можете точно определить, когда и как часто EF выполняет запросы, и какие запросы он выполняет.

На что обратить внимание:

• Сколько запросовБег?Если вы загружаете набор записей и ожидаете одного запроса, существует ли целая куча отправляемых запросов?Это будет указывать на инициируемые вызовы с отложенной загрузкой.
• Какие запросы выполняются?Выбирает ли он намного больше полей, чем отображается?Это может быть случай, когда целые объекты загружаются, где .Select() может использоваться для уменьшения объема данных.Возможно, даже в случае, когда загружаются целые наборы сущностей, которые не имеют отношения к тому, что отображается / выполняется, например, случаи, когда кто-то использует .ToList() перед тем, как просто выполнить .Count() или .Any() или выполнить .FirstOrDefault() только для проверки != null.
• Правильно ли проиндексирована база данных?Скопируйте некоторые из более тяжелых запросов в SQL Manager и выполните их с планом выполнения.Существуют ли предложения по индексированию?

Общие грехи разработки с EF и другими ORM сводятся к тому, чтобы «тянуть слишком много, слишком часто».Удивительно, как много клиентов, с которыми я работал, имеют команды разработчиков, которые не использовали профилировщик для проверки эффективности использования ORM.(и я пока говорю 0%.)

Answer 2

Если оно «истекло» и если «увеличение DTU разрешает тайм-ауты», и эти наблюдения верны (я думаю, что вы действительно должны убедить себя, что это абсолютно верно, не делайте это предположение легкомысленным), тогда обычное и очевидноеКандидат "медленный SQL-запрос".Entity Framework часто используется с linq для создания sql запросов без написания sql.Эти запросы часто подходят для очень простых задач, таких как someData.Where (x => x.Id == 1) .First (), однако, если linq используется для объединения таблиц или создания сложных ассоциаций, сгенерированный sql можетстать чудовищно плохим, с точки зрения производительности.Вы можете добавить протоколирование, чтобы записать sql, сгенерированный linq, или вы можете попытаться отследить базу данных, чтобы увидеть, что sql работает на ней.Если о трассировке не может быть и речи, по-прежнему существуют мета-запросы, которые можно использовать для просмотра таких вещей, как планы с кэшированными запросами, а SQL Server может подсчитать приблизительные затраты и число выполнений в кэше.

Вы все еще можете повеситься, не используя linq,Вы все еще можете использовать хранимые процедуры с EF.Слишком много разработчиков наивно относятся к производительности SQL все же ;вам нужно прочесать свой бэкэнд и изучить схему, хранимые процедуры;проверить содержимое sql всего.Проверьте на любые триггеры базы данных (легко пропустить).Красные флаги - это подзапросы, слишком много объединений, слишком много результатов из запроса, много манипуляций со строками в запросе, объединение таблиц в строках или работа с SQL на основе XML / JSON.

Помните, что "медленный sql"запросы "станут медленнее, когда нагрузка высокая.И когда создаются медленные SQL-запросы, для их решения требуется больше времени.Это также может привести к изнурительной блокировке таблицы, в зависимости от характера запроса.

Но запросы могут быть эффективными и по-прежнему вызывать блокировку.то есть одна таблица часто записывается и блокирует другие записи или чтения из этой таблицы.Это немного сложнее диагностировать, но вы можете выяснить это, внимательно изучив журналы вызовов базы данных и время их выполнения.Существуют также SQL-запросы, которые вы можете запускать в базе данных для диагностики долговременных запросов или таблиц, которые заблокированы в данный момент времени.

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

Но это все предположение.Я думаю, вам нужно провести дополнительные исследования, чтобы определить, что на самом деле приводит к тому, что сайт перестает отвечать на запросы.Если вы можете регистрировать время отклика для общих запросов, вы можете исключить задержку на основе SQL как виновника или нет, и работать с этого момента.По сути, нет ничего «неправильного» ни в одной из указанных вами технологий.

Если запросы постоянны, но все еще вызывают проблемы, долгосрочным решением является добавление чего-то вроде очереди сообщений и интеллектуальная пакетная обработка SQL или простосделайте базу данных асинхронной и не блокируйте пользовательский интерфейс.

Вы должны соотнести любые зарегистрированные таймауты с мониторингом Azure.Azure может предоставить вам посещение ЦП / ОЗУ / страницы и тому подобное на панели инструментов.