Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта статья поможет устранить причины снижения производительности приложения, размещенного в Службе приложений Azure.
Если вам нужна дополнительная помощь в любой момент этой статьи, обратитесь к экспертам Azure в службе поддержки сообщества Azure. Кроме того, можно зарегистрировать обращение в службу поддержки Azure. Перейдите в службу поддержки Azure и выберите " Отправить запрос в службу поддержки".
Симптом
При просмотре приложения страницы загружают медленно и иногда истекает время ожидания.
Причина
Эта проблема часто связана с проблемами на уровне приложения, например:
- Сетевые запросы занимает много времени
- Код приложения или запросы базы данных неэффективны
- Приложение с высокой памятью и ЦП
- Сбой приложения из-за исключения
Действия по устранению неполадок
Процесс устранения неполадок можно разделить на три последовательных задачи.
Служба приложений содержит несколько параметров для каждого из этих этапов.
Наблюдение и мониторинг поведения приложения
Отслеживание работоспособности службы
Azure предоставляет доступ к каждому прерыванию службы или снижению производительности. Вы можете отслеживать работоспособность службы на портале Azure. Дополнительные сведения см. в разделе "Просмотр уведомлений о работоспособности службы" с помощью портала Azure.
Отслеживание работы приложения
Средства мониторинга можно использовать на портале Azure, чтобы узнать, есть ли у приложения какие-либо проблемы. В разделе "Мониторинг " в боковом меню выберите "Метрики". В раскрывающемся меню метрик отображаются все метрики , которые можно добавить.
Некоторые метрики, которые могут потребоваться отслеживать для приложения, включают:
- средний размер рабочего набора памяти;
- Время ЦП
- Рабочий набор памяти
- Запросы
- Время ответа
Дополнительные сведения см. в разделе:
состояния конечной веб-точки
Если приложение работает в ценовой категории "Стандартный ", служба приложений позволяет отслеживать две конечные точки из трех географических расположений.
Функция мониторинга конечных точек настраивает веб-тесты из географически распределенных местоположений, позволяя проверить время ответа и время непрерывной работы URL-адресов. Тест выполняет HTTP GET операцию на URL-адресе, чтобы определить время отклика и время безотказной работы в каждом месте. Для каждого настроенного расположения тест выполняется каждые пять минут.
Время непрерывной работы контролируется при помощи кодов ответов HTTP, а время ответа измеряется в миллисекундах. Тест завершается с ошибкой, если код ответа HTTP больше или равен 400 или если на ответ требуется более 30 секунд. Конечная точка считается доступной, если тесты мониторинга завершились для нее успешно для всех указанных расположений.
Сведения о настройке см. в статье "Квоты и метрики службы приложений Azure".
Мониторинг производительности приложений с помощью расширений
Кроме того, вы можете отслеживать производительность приложения через расширение сайта.
Каждое приложение службы приложений предоставляет расширяемую конечную точку управления, которая позволяет использовать мощный набор средств, развернутых в качестве расширений сайта. Расширения включают в себя:
- Редакторы исходного кода, такие как GitHub Codespaces.
- Инструменты управления для подключенных ресурсов, например базы данных MySQL, подключенной к приложению.
Также доступно расширение сайта для мониторинга производительности Azure Application Insights. Чтобы использовать Application Insights, перестройте код с помощью пакета SDK. Кроме того, вы можете установить расширение, которое предоставляет доступ к дополнительным данным. Пакет SDK позволяет писать код для более подробного отслеживания использования и производительности приложения. Дополнительные сведения см. в статье "Введение в Application Insights — Наблюдаемость OpenTelemetry".
Сбор данных
Службы приложений включают функции диагностики для записи в журнал информации как с веб-сервера, так и из веб-приложения. Информация разделена следующим образом: диагностика веб-сервера и диагностика приложений.
Включение диагностики веб-сервера
Вы можете включить или отключить такие виды журналов:
- Подробное ведение журнала ошибок: подробные сведения об ошибках для кодов состояния HTTP, которые указывают на сбой (код состояния 400 или больше). Это может содержать сведения, которые помогут определить, почему сервер вернул код ошибки.
- Трассировка неудачных запросов: подробные сведения о неудачных запросах, включая трассировку компонентов IIS, используемых для обработки запроса и времени, затраченного на каждый компонент. Это может быть полезно, если вы пытаетесь повысить производительность приложения или изолировать то, что вызывает определенную ошибку HTTP.
- Ведение журнала веб-сервера: сведения о http-транзакциях с использованием формата расширенного файла журнала W3C. Это удобно при определении общих метрик приложения, например, количества обработанных запросов или количества запросов с определенного IP-адреса.
Включение диагностики приложений
Доступно несколько параметров сбора данных о производительности приложений из Службы приложений: динамическое профилирование приложения из Visual Studio или изменения кода приложения для записи в журналы дополнительных сведений и трассировок. Эти параметры можно выбрать в зависимости имеющегося уровня доступа к приложению и информации, собранной инструментами мониторинга.
Использование Application Insights Profiler
Вы можете включить Application Insights Profiler, чтобы начать запись подробных трассировок производительности. Вы можете получить доступ к трассировкам, захваченным за последние пять дней, когда вам нужно изучить проблемы. Этот параметр можно выбрать при условии, что у вас имеется доступ к ресурсу Application Insights приложения на портале Azure.
Application Insights Profiler предоставляет статистику времени отклика для каждого веб-вызова и трассировки, которые показывают, какая строка кода вызвала медленные ответы. Иногда приложение службы приложений медленно, так как определенный код не записывается в производительном режиме. К таким кодам относится последовательный код, который может выполняться параллельно и вызывать нежелательные конфликты в базе данных. Удаление этих узких мест в коде повышает производительность приложения, но их трудно обнаружить без настройки сложных трассировок и журналов. Данные трассировки, собранные Application Insights Profiler, помогают найти строки кода, замедляющие работу приложения, и устранить эту проблему для приложений службы приложений.
Дополнительные сведения см. в разделе "Включение профилировщика .NET для приложений службы приложений Azure" в Windows.
Настройка диагностических трассировок вручную
Если у вас есть доступ к исходному коду веб-приложения, диагностика приложений позволяет записывать сведения, созданные веб-приложением. Приложения ASP.NET могут использовать класс System.Diagnostics.Trace для записи информации в журнал диагностики приложений. Тем не менее необходимо изменить код приложения и повторно развернуть его. Этот метод рекомендуется в том случае, если приложение выполняется в тестовой среде.
Подробные инструкции по настройке приложения для ведения журнала см. в статье "Включение ведения журнала диагностики для приложений в Службе приложений Azure".
Использование средства диагностики
Служба приложений не требует никакой настройки и предоставляет вам интеллектуальный и интерактивный интерфейс для устранения неполадок в приложении. При возникновении проблем с приложением средство диагностики указывает на то, что неправильно, чтобы вам было проще и быстрее устранять проблему.
Чтобы открыть диагностику службы приложений, перейдите на портале Azure к приложению службы приложений или к среде службы приложений. В меню боковой панели выберите " Диагностика и решение проблем".
Использование консоли отладки Kudu
Служба приложений оснащена консолью отладки, с помощью которой вы можете получать сведения о среде, используя функции отладки, изучения, передачи файлов и конечных точек JSON. Она называется консоль Kudu или панель мониторинга SCM приложения.
Вы можете получить доступ к этой панели мониторинга, перейдя на сайт Kudu.
Вот некоторые возможности консоли Kudu:
- Параметры среды для приложения
- Поток логов
- Диагностический дамп
- Консоль отладки, в которой можно запускать командлеты PowerShell и основные команды DOS
У консоли Kudu есть еще одна очень полезная функция. Если приложение создает обрабатываемые исключения, с помощью консоли Kudu и средства SysInternals Procdump вы можете получать дампы памяти. Эти дампы памяти представляют собой снимок процессов и могут помочь в устранении сложных проблем в приложении.
Дополнительные сведения о функциях, доступных в Kudu, см. в веб-инструментах Веб-сайтов Windows Azure, о которые вы должны знать.
Устранение проблемы
Масштабирование приложения
В Службе приложений для повышения производительности и пропускной способности можно настроить масштаб, в котором выполняется приложение. Масштабирование приложения включает в себя два связанных действия: изменение плана службы приложений на более высокую ценовую категорию и настройку определенных параметров после перехода на более высокую ценовую категорию.
Дополнительные сведения о масштабировании см. в статье Увеличение масштаба приложения в Azure.
Кроме того, вы можете запустить более одного экземпляра приложения. Увеличение масштаба не только увеличит возможности обработки, но и повысит отказоустойчивость приложения. Если прекратит работу процесс на одном экземпляре, другой экземпляр продолжит обрабатывать запросы.
Масштабирование можно задать вручную или автоматически.
Использовать автоматическое восстановление
Автоматическое исцеление перезапускает рабочий процесс для приложения на основе параметров, которые вы выбираете, например изменения конфигурации, запросы, ограничения на основе памяти или время, необходимое для выполнения запроса. Большую часть времени, переработка процесса является самым быстрым способом восстановления от проблемы. Хотя вы всегда можете перезапустить приложение непосредственно на портале Azure, автоматическое восстановление выполняется автоматически для вас. Для этого достаточно добавить в корневой файл web.config вашего приложения некоторые триггеры. Эти параметры будут работать так же, даже если приложение не является приложением .NET.
Дополнительные сведения см. в статье об автоматическом восстановлении веб-сайтов Microsoft Azure.
Перезапуск приложения
Обычно перезапуск — самый простой способ восстановления работы после проблемы, которая возникла один раз. На портале Azure можно остановить или перезапустить приложение.
Вы также можете управлять приложением с помощью Azure PowerShell. Дополнительные сведения см. в статье Управление ресурсами Azure с помощьюAzure PowerShell.