Поделиться через


Устранение причин низкой производительности приложения в Службе приложений Azure

Эта статья поможет устранить причины снижения производительности приложения, размещенного в Службе приложений Azure.

Если вам потребуется дополнительная помощь по любому из вопросов, рассматриваемых в статье, вы можете обратиться к экспертам по Azure на форумах MSDN Azure и Stack Overflow. Кроме того, можно зарегистрировать обращение в службу поддержки Azure. Перейдите на сайт службы поддержки Azure и щелкните Поддержка.

Симптом

При просмотре приложения загрузка страницы идет медленно и иногда может превысить время ожидания.

Причина

Эта проблема часто связана с проблемами на уровне приложения, например:

  • слишком долгое выполнение сетевых запросов;
  • неэффективный код приложения или запросы к базе данных;
  • слишком высокие требования приложения к памяти и процессору;
  • сбой приложения из-за исключения.

Действия по устранению неполадок

Процесс устранения неполадок можно разделить на три последовательных задачи.

  1. Наблюдение за поведением приложения.
  2. Сбор данных.
  3. Устранение проблемы.

Служба приложений содержит несколько параметров для каждого из этих этапов.

1. Мониторинг и мониторинг поведения приложения

Мониторинг работоспособности службы

Microsoft Azure информирует о каждом случае прерывания работы или снижения производительности службы. За работоспособностью службы можно следить на портале Azure. Дополнительные сведения см. в статье Получение информации о работоспособности службы.

Отслеживание работы приложения

Этот инструмент позволяет определить наличие проблем с приложением. В колонке вашего приложения щелкните на плитку Запросы и ошибки. Колонка Метрика содержит все метрики, которые вы можете добавить.

Некоторые из этих метрик помогут вам отслеживать работу приложения, например,

  • средний размер рабочего набора памяти;
  • Время ответа
  • Время ЦП
  • Рабочий набор памяти
  • Запросы

Мониторинг производительности приложения

Дополнительные сведения см. в разделе:

состояния конечной веб-точки

Если вы запускаете приложение в ценовой категории Стандартный, то Служба приложений позволяет отслеживать две конечные точки из трех географических расположений.

Функция мониторинга конечных точек настраивает веб-тесты из географически распределенных местоположений, позволяя проверить время ответа и время непрерывной работы URL-адресов. Тест выполняет операцию HTTP GET для URL-адреса веб-приложения и определяет время ответа и время непрерывной работы для каждого местоположения. Для каждого настроенного расположения тест выполняется каждые пять минут.

Время непрерывной работы контролируется при помощи кодов ответов HTTP, а время ответа измеряется в миллисекундах. Тест завершается с ошибкой, если код ответа HTTP больше или равен 400 или если на ответ требуется более 30 секунд. Конечная точка считается доступной, если тесты мониторинга завершились для нее успешно для всех указанных расположений.

Настройка описана в статье Мониторинг приложений в службе приложений Azure.

Кроме того, вы можете посмотреть видео, посвященное контролю конечных точек: Поддержка работы веб-сайтов Azure с помощью мониторинга конечных точек (со Стефаном Щаковым ((Stefan Schackow)) .

Контроль производительности приложений с помощью расширений

Кроме того, вы можете отслеживать производительность приложения через расширение сайта.

Каждое приложение Службы приложений дает возможность использовать расширяемую конечную точку управления, которая позволяет применять набор мощных инструментов, развернутых в виде расширений сайта. Расширения включают в себя:

  • Редакторы исходного кода, такие как Azure DevOps.
  • Инструменты управления для подключенных ресурсов, например базы данных MySQL, подключенной к приложению.

Также доступно расширение сайта для мониторинга производительности Azure Application Insights. Чтобы использовать Application Insights, перестройте код с помощью пакета SDK. Кроме того, вы можете установить расширение, которое предоставляет доступ к дополнительным данным. Пакет SDK позволяет писать код для более подробного отслеживания использования и производительности приложения. Дополнительные сведения см. в разделе о мониторинге производительности в веб-приложениях.

2. Сбор данных

Службы приложений включают функции диагностики для записи в журнал информации как с веб-сервера, так и из веб-приложения. Информация разделена следующим образом: диагностика веб-сервера и диагностика приложений.

Включение диагностики веб-сервера

Вы можете включить или отключить такие виды журналов:

  • Подробное ведение журнала ошибок — регистрация подробной информации об ошибке для кодов состояния HTTP, которые указывают на сбой (код состояния 400 и выше). Здесь могут содержаться сведения, которые помогут определить причину, по которой сервер вернул код ошибки.
  • Трассировка неудачно завершенных запросов — регистрация подробной информации о неудачных запросах, включая трассировку компонентов IIS для обработки запроса и время каждого компонента. Это может быть полезно, если вы пытаетесь повысить производительность приложения или определить причину конкретной ошибки HTTP.
  • Журналы веб-сервера — регистрация сведений о HTTP-транзакциях в расширенном формате файла журнала W3C. Это удобно при определении общих метрик приложения, например, количества обработанных запросов или количества запросов с определенного IP-адреса.

Включение диагностики приложений

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

Использование Application Insights Profiler

Вы можете включить Application Insights Profiler, чтобы начать запись подробных трассировок производительности. Можно просмотреть трассировки, записанные за последние пять дней, если требуется изучить проблемы, возникшие в прошлом. Этот параметр можно выбрать при условии, что у вас имеется доступ к ресурсу Application Insights приложения на портале Azure.

Application Insights Profiler предоставляет статистику по времени отклика каждого веб-вызова и выполняет трассировку, что помогает определить строку кода, которая привела к медленным откликам. Иногда приложение службы приложений работает медленно из-за определенного кода, который обеспечивает низкопроизводительное выполнения. К таким кодам относится последовательный код, который может выполняться параллельно и вызывать нежелательные конфликты в базе данных. Удаление этих узких мест в коде позволяет увеличить производительность приложения, но их трудно определить без настройки сбора событий трассировки и журналов. Данные трассировки, собранные Application Insights Profiler, помогают найти строки кода, замедляющие работу приложения, и устранить эту проблему для приложений службы приложений.

Дополнительные сведения см. в статье Профилирование динамических приложений Службы приложений Azure с помощью Application Insights.

Используйте удаленное профилирование

Служба приложений Azure позволяет удаленно профилировать веб-приложения, приложения API, серверные части мобильных решений и веб-задания. Выберите этот параметр, если у вас имеется доступ к ресурсу приложения и вы знаете, как воспроизвести проблему, либо вам известен точный интервал времени, на котором были выявлены проблемы производительности.

Если процесс потребляет слишком много ресурсов ЦП и выполняется медленнее, чем вы ожидали, или если задержка HTTP-запросов выше обычной, то вы можете удаленно профилировать такой процесс. Вы получите стеки вызовов с выборками циклов ЦП, по которым можно выполнить анализ действий процесса и критических путей в программном коде.

Дополнительные сведения см. в статье Поддержка удаленного профилирования в службе приложений Azure.

Настройка диагностических трассировок вручную

Если у вас имеется доступ к исходному коду веб-приложения, то с помощью диагностики приложений вы сможете записывать сведения, созданные этим веб-приложением. Приложения ASP.NET могут использовать класс System.Diagnostics.Trace для записи информации в журнал диагностики приложений. Тем не менее необходимо изменить код приложения и повторно развернуть его. Этот метод рекомендуется в том случае, если приложение выполняется в тестовой среде.

Подробные инструкции по настройке приложения для ведения журнала вы можете изучить в статье Включение ведения журнала диагностики для приложений в Службе приложений Azure.

Использование средства диагностики

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

Чтобы открыть диагностику службы приложений, перейдите на портале Azure к приложению службы приложений или к среде службы приложений. На панели навигации слева щелкните Диагностика и решение проблем.

Использование консоли отладки Kudu

Служба приложений оснащена консолью отладки, с помощью которой вы можете получать сведения о среде, используя функции отладки, изучения, передачи файлов и конечных точек JSON. Она называется консоль Kudu или панель мониторинга SCM приложения.

Вы можете открыть эту панель по ссылке https://<имя приложения>.scm.azurewebsites.net/.

Вот некоторые возможности консоли Kudu:

  • настройки среды для вашего приложения;
  • потоковая передача журналов;
  • диагностический дамп;
  • консоль отладки с возможностью запуска командлетов PowerShell и основных команд DOS.

У консоли Kudu есть еще одна очень полезная функция. Если приложение создает обрабатываемые исключения, с помощью консоли Kudu и средства SysInternals Procdump вы можете получать дампы памяти. Эти дампы памяти представляют собой снимок процессов и могут помочь в устранении сложных проблем в приложении.

Дополнительные сведения о возможностях консоли Kudu см. в статье Azure DevOps tools you should know about (Инструменты Azure DevOps, о которых вам нужно знать).

3. Устранение проблемы

Масштабирование приложения

В службе приложений Azure вы можете изменять масштаб выполнения приложения, чтобы увеличить его производительность и пропускную способность. Масштабирование приложения предполагает два связанных действия: изменение ценовой категории для используемого плана службы приложений на более высокую с последующей настройкой некоторых параметров.

Дополнительные сведения о масштабировании см. в статье Увеличение масштаба приложения в Azure.

Кроме того, вы можете запустить более одного экземпляра приложения. Увеличение масштаба не только увеличит возможности обработки, но и повысит отказоустойчивость приложения. Если прекратит работу процесс на одном экземпляре, другой экземпляр продолжит обрабатывать запросы.

Вы можете выбрать ручной или автоматический режим масштабирования.

Использование функции AutoHeal

Функция AutoHeal перезапускает рабочий процесс вашего приложения при определенных условиях, которые вы определяете в настройках (например, при изменении конфигурации, при определенном количестве запросов, при достижении ограничений памяти или времени выполнения запроса). В большинстве случаев повторный запуск процесса будет самым быстрым способом устранения проблемы. Хотя приложение всегда можно вручную перезапустить на портале Azure, функция AutoHeal позволяет сделать это автоматически. Для этого достаточно добавить в корневой файл web.config вашего приложения некоторые триггеры. Эти параметры одинаково работают во всех приложениях, а не только в приложениях .NET.

Дополнительные сведения см. в статье об автоматическом восстановлении веб-сайтов Microsoft Azure.

Перезапуск приложения

Обычно перезапуск — самый простой способ восстановления работы после проблемы, которая возникла один раз. Остановить или перезапустить приложение можно с помощью колонки вашего приложения на портале Azure.

Перезапуск приложения для устранения проблем с производительностью

Вы также можете управлять приложением с помощью Azure PowerShell. Дополнительные сведения см. в статье Использование Azure PowerShell с диспетчером ресурсов Azure.

Дополнительные ресурсы

Учебник. Выполнение нагрузочного теста для выявления узких мест производительности в веб-приложении