Часто задаваемые вопросы о производительности приложений для веб-приложения в Azure

Статья
07/17/2023

Примечание.

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

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

Если проблема с Azure не устранена в этой статье, посетите форумы Azure на веб-сайтах MSDN и Stack Overflow. Вы можете опубликовать свою проблему на этих форумах или опубликовать на @AzureSupport в Twitter. Вы также можете отправить запрос на поддержка Azure. Чтобы отправить запрос на поддержку, на странице поддержка Azure выберите Получить поддержку.

Почему мой план Служба приложений отображает использование ЦП и памяти, даже если все веб-приложения остановлены?

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

Системные процессы будут выполняться в планах Служба приложений, даже если не выполняется веб-приложения или если план Служба приложений не содержит веб-приложения.

Процессы платформы будут потреблять минимальное количество ресурсов (например, ЦП, память и дисковое пространство), и то же самое должно учитываться при планировании емкости, мониторинге и автоматическом масштабировании триггера плана Служба приложений.

Почему мое приложение работает медленно?

Несколько факторов могут способствовать снижению производительности приложения. Подробные инструкции по устранению неполадок см. в статье Устранение неполадок с низкой производительностью веб-приложения.

Разделы справки устранить неполадки в сценарии с высоким потреблением ЦП?

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

Разделы справки устранить неполадки в сценарии с высоким потреблением памяти?

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

Разделы справки автоматизировать веб-приложения Служба приложений с помощью PowerShell?

Командлеты PowerShell можно использовать для управления и обслуживания Служба приложений веб-приложений. В записи блога Автоматизация веб-приложений, размещенных в Служба приложений Azure с помощью PowerShell, мы описываем, как использовать командлеты PowerShell на основе Azure Resource Manager для автоматизации распространенных задач. В записи блога также содержится пример кода для различных задач управления веб-приложениями. Описания и синтаксис всех командлетов веб-приложений Служба приложений см. в разделе Az.Websites.

Разделы справки просматривать журналы событий веб-приложения?

Чтобы просмотреть журналы событий веб-приложения, выполните приведенные ниже действия.

Войдите на веб-сайт Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
В меню выберите Отладка Консоль>CMD.
Выберите папку LogFiles .
Чтобы просмотреть журналы событий, щелкните значок карандаша рядом сeventlog.xml.
Чтобы скачать журналы, выполните командлет Save-AzureWebSiteLog -Name webappnamePowerShell .

Разделы справки записать дамп памяти в пользовательском режиме моего веб-приложения?

Чтобы записать дамп памяти в пользовательском режиме веб-приложения, выполните следующее:

Войдите на веб-сайт Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
Выберите меню Обработка Обозреватель.
Щелкните правой кнопкой мыши процессw3wp.exe или процесс веб-задания.
Выберите Скачать полный дамп> памяти.

Разделы справки просмотреть сведения об уровне процесса для моего веб-приложения?

У вас есть два варианта просмотра сведений на уровне процесса для веб-приложения:

На портале Azure выполните следующие действия:
1. Откройте Обозреватель процесса для веб-приложения.
2. Чтобы просмотреть сведения, выберите процессw3wp.exe .
В консоли Kudu:
1. Войдите на веб-сайт Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
2. Выберите меню Обработка Обозреватель.
3. Для процессаw3wp.exe выберите Свойства.

При переходе к приложению отображается сообщение "Ошибка 403 — это веб-приложение остановлено". Разделы справки устранить эту проблему?

Эту ошибку могут вызвать три условия:

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

Чтобы узнать, что вызывает ошибку и устранить проблему, выполните действия, описанные в веб-приложения: "Ошибка 403 — это веб-приложение остановлено".

Где можно узнать больше о квотах и ограничениях для различных планов Служба приложений?

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

Разделы справки уменьшить время отклика на первый запрос после простоя?

По умолчанию веб-приложения выгружаются, если они простаивают в течение заданного периода времени. Таким образом система может экономить ресурсы. Недостаток заключается в том, что ответ на первый запрос после выгрузки веб-приложения дольше, чтобы веб-приложение загружалось и начинало обслуживать ответы. В планах обслуживания "Базовый" и "Стандартный" можно включить параметр Always On, чтобы приложение всегда загружалось. Это позволяет избежать более длительного времени загрузки после простоя приложения. Чтобы изменить параметр Always On, выполните следующие действия:

В портал Azure перейдите к веб-приложению.
Выбор конфигурации
Выберите Общие параметры.
Для Always On выберите Включено.

Разделы справки включить трассировку неудачных запросов?

Чтобы включить трассировку неудачных запросов, выполните следующие действия.

В портал Azure перейдите к веб-приложению.
Выберите Все параметры Журналы>диагностики.
Для параметра Трассировка неудачных запросов выберите Включено.
Нажмите кнопку Сохранить.
В колонке веб-приложения выберите Сервис.
Выберите Visual Studio Online.
Если параметр не включен, выберите Включено.
Выберите Выполнить.
Выберите Web.config.

В system.webServer добавьте следующую конфигурацию (для записи определенного URL-адреса):

<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*api*" />
<add path="*api*">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

Чтобы устранить проблемы с низкой производительностью, добавьте следующую конфигурацию (если запрос записи занимает более 30 секунд):

<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*" />
<add path="*">
<traceAreas> <add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

Чтобы скачать трассировки неудачных запросов, на портале перейдите на веб-сайт.
Выберите Сервис>Kudu>Go.
В меню выберите Отладка Консоль>CMD.
Выберите папку LogFiles , а затем выберите папку с именем, начинающимся с W3SVC.
Чтобы просмотреть XML-файл, щелкните значок карандаша.

Отображается сообщение "Рабочий процесс запросил перезапуск из-за ограничения "Процент памяти". Разделы справки устранить эту проблему?

Максимальный объем памяти для 32-разрядного процесса (даже в 64-разрядной операционной системе) составляет 2 ГБ. По умолчанию рабочий процесс имеет значение 32-разрядный в Служба приложений (для совместимости с устаревшими веб-приложениями).

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

Кроме того, обратите внимание, что для 64-разрядной среды требуется базовый или стандартный план обслуживания. Бесплатные и общие планы всегда выполняются в 32-разрядной среде.

Дополнительные сведения см. в разделе Настройка веб-приложений в Служба приложений.

Почему истекает время ожидания запроса через 230 секунд?

Azure Load Balancer по умолчанию установлено время ожидания простоя в четыре минуты. Как правило, этот параметр является разумным ограничением времени отклика для веб-запроса. таким образом, Служба приложений возвращает клиенту время ожидания, если приложение не возвращает ответ в течение примерно 240 секунд (230 секунд в приложении Windows, 240 секунд в приложении Linux).　Если вашему веб-приложению требуется фоновая обработка, рекомендуется использовать веб-задания Azure. Веб-приложение Azure может вызывать веб-задания и получать уведомления о завершении фоновой обработки. Для использования веб-заданий можно выбрать один из нескольких методов, включая очереди и триггеры.

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

ASP.NET Core приложения, размещенные в Служба приложений иногда перестают отвечать на запросы. Разделы справки устранить эту проблему?

Известная проблема с более ранней версией Kestrel может привести к тому, что приложение ASP.NET Core 1.0, размещенное в Служба приложений, периодически перестает отвечать на запросы. Вы также можете увидеть следующее сообщение: "В указанном приложении CGI произошла ошибка, и сервер завершил процесс".

Эта проблема устранена в Kestrel версии 1.0.2. Эта версия включена в обновление ASP.NET Core 1.0.3. Чтобы устранить эту проблему, обязательно обновите зависимости приложения для использования Kestrel 1.0.2. Кроме того, можно использовать одно из двух обходных решений, описанных в записи блога ASP.NET Core проблем с медленным переувыполком 1.0 в Служба приложений веб-приложениях.

Не удается найти файлы журнала в файловой структуре веб-приложения. Как их найти?

Если вы используете функцию локального кэша Служба приложений, структура папок LogFiles и папки данных для экземпляра Служба приложений будут затронуты. При использовании локального кэша в папках LogFiles и Data хранилища создаются вложенные папки. Вложенные папки используют шаблон именования "уникальный идентификатор" + метку времени. Каждая вложенная папка соответствует экземпляру виртуальной машины, в которой запущено или запущено веб-приложение.

Чтобы определить, используется ли локальный кэш, проверка вкладку параметры приложения Служба приложений. Если используется локальный кэш, параметр WEBSITE_LOCAL_CACHE_OPTION приложения имеет значение Always.

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

Отображается сообщение "Предпринята попытка доступа к сокету способом, запрещенным его разрешениями на доступ". Разделы справки устранить эту ошибку?

Эта ошибка обычно возникает, если исходящие TCP-подключения на экземпляре виртуальной машины исчерпаны. В Служба приложений применяются ограничения для максимального числа исходящих подключений, которые могут быть установлены для каждого экземпляра виртуальной машины. Дополнительные сведения см. в разделе Числовые ограничения между виртуальными машинами.

Эта ошибка также может возникнуть при попытке получить доступ к локальному адресу из приложения. Дополнительные сведения см. в разделе Запросы локальных адресов.

Дополнительные сведения об исходящих подключениях в веб-приложении см. в записи блога об исходящих подключениях к веб-сайтам Azure.

Разделы справки использовать Visual Studio для удаленной отладки веб-приложения Служба приложений?

Подробное пошаговое руководство по отладке веб-приложения с помощью Visual Studio см. в статье Удаленная отладка веб-приложения Служба приложений.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.