Рекомендации по использованию Службы приложений Azure

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

Совместное размещение

Если входящие в решение ресурсы Azure, например веб-приложения и базы данных, находятся в разных регионах, возможны следующие последствия:

  • увеличение задержки при взаимодействии между ресурсами,
  • денежные расходы на передачу данных между регионами в соответствии со стоимостью услуг Azure.

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

Если приложения используют больше памяти, чем ожидалось

Если вы заметите по данным мониторинга или по рекомендациям службы, что приложение использует больше памяти, чем ожидалось, попробуйте применить функцию автоматического восстановления службы приложений. В одном из режимов работы функция автоматического восстановления выполняет действия с учетом заданного порога использования памяти. Возможные действия включают уведомления по электронной почте, исследования с помощью дампа памяти, мгновенное реагирование с перезапуском рабочего процесса. Функция автоматического восстановления настраивается через файл web.config или через удобный пользовательский интерфейс, как описано в записи блога App Service Support Site Extension(Расширение сайта поддержки для службы приложений).

Если приложения используют больше ресурсов ЦП, чем ожидалось

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

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

Если исчерпаны ресурсы сокетов

Резерв исходящих TCP-подключений обычно исчерпывается, если используемые клиентские библиотеки не поддерживают повторное использование TCP-подключений или не используют метод проверки активности (Keep-Alive) для протоколов более высокого уровня (например, HTTP). Ознакомьтесь с документацией по каждой библиотеке, на которые ссылаются приложения в вашем плане службы приложений, и убедитесь, что настройка этих библиотек и методы их вызова обеспечивают эффективное повторное использование исходящих подключений. Также выполните все приведенные в документации рекомендации по правильному созданию, освобождению и очистке подключений, чтобы избежать утечки данных во время подключений. Пока выполняется эта проверка клиентских библиотек, последствия можно временно устранить, увеличив количество экземпляров.

Node.js и исходящие HTTP-запросы

При работе с Node.js и большим числом исходящих HTTP-запросов важна поддержка открытых соединений HTTP. Чтобы упростить код, вы можете использовать пакет agentkeepalive.

Обязательно выполняйте обработку ответа http, даже при отсутствии действий в обработчике. Если не обработать ответ надлежащим образом, в работе приложения со временем возникнут затруднения, так как не останется дополнительных сокетов.

Например, при работе с пакетом http или https:

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

Если служба приложений на платформе Linux работает на компьютере с несколькими ядрами, рекомендуем использовать PM2, чтобы запустить несколько процессов Node.js для выполнения приложения. Для этого можно указать команду запуска контейнера.

Например, чтобы запустить четыре экземпляра:

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

Когда начинаются сбои архивации приложения

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

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

Развертывание новых приложений Node.js в службе приложений Azure

Конфигурация по умолчанию службы приложений Azure для приложений Node.js предназначена для наиболее распространенных из них. Если в конфигурации для приложения Node.js целесообразно использовать персонализированные настройки, чтобы повысить производительность или оптимизировать использование ресурсов ЦП, памяти и сети, ознакомьтесь со статьей Рекомендации и руководство по устранению неполадок приложений Node в веб-приложениях Azure. В этой статье описаны параметры IISNode, которые может потребоваться настроить для приложения Node.js. В ней также рассмотрены различные сценарии и проблемы, которые могут возникнуть при работе приложения, и показано, как устранить эти проблемы.

Next Steps

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

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

Вы также можете использовать эту ссылку, чтобы напрямую открыть диагностику службы приложений для вашего ресурса: https://ms.portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.