Рекомендации и руководство по устранению неполадок в приложениях Node.js в Службе приложений Azure (Windows)

Сводка

В этой статье описываются рекомендации и способы устранения неполадок приложений Node.js для Windows, запущенных в службе приложений Azure (с помощью iisnode).

Конфигурация IISNODE

В этом файле схемы показаны все параметры, которые вы можете настроить для iisnode. Ниже приведены параметры, которые полезны для вашего приложения:

Количество процессов узла на приложение

Этот параметр определяет количество процессов Node, запущенных в одном приложении IIS. Значение по умолчанию — 1. Вы можете запустить столько процессов node.exe, сколько виртуальных ЦП виртуальной машины, изменив значение на 0. Рекомендуемое для многих приложений значение 0 позволяет использовать все доступные виртуальные ЦП.

Хотя цикл событий Node.js выполняется в одном потоке, один процесс Node.js по-прежнему может использовать несколько ядер ЦП, если приложение использует рабочие потоки, модуль кластера, собственные надстройки или другие библиотеки, которые выполняются параллельно. Для рабочих нагрузок, связанных с ЦП, можно получить более высокую пропускную способность, выполнив несколько процессов Node.js (до количества виртуальных ЦП виртуальной машины), чтобы службы IIS могли распределять запросы между процессами.

командная строка процесса узла

Этот параметр определяет путь к файлу node.exe. Это значение можно задать таким образом, чтобы оно указывало версию файла node.exe.

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

Этот параметр определяет максимальное количество одновременных запросов, отправленных с помощью iisnode в каждый файл node.exe. В службе приложений Azure по умолчанию используется значение Infinite. Его можно изменить с учетом числа запросов, получаемых приложением, и скорости их обработки.

максПовторСоединенияЧерезНазваннуюТрубку

Этот параметр определяет максимальное число повторных подключений iisnode к именованному каналу для отправки запросов в node.exe. В сочетании с параметром namedPipeConnectionRetryDelay он определяет общее значение времени ожидания каждого запроса в iisnode. В службе приложений Azure для этого параметра по умолчанию задано значение 200. Полное время ожидания в секундах = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000.

задержка повторного подключения именованного канала

Этот параметр определяет интервал времени (в мс), который iisnode ожидает между каждой попыткой повторной отправки запроса в node.exe через именованный канал. Значение по умолчанию — 250 мс. Общее время ожидания в секундах = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

По умолчанию общее время ожидания для iisnode в Службе приложений Azure составляет 200 * 250 мс = 50 секунд.

logDirectory

Этот параметр определяет каталог, в который iisnode записывает сведения журналов stdout и stderr. По умолчанию для этого параметра задано значение iisnode. Оно задается относительно основного каталога скрипта (каталога, в котором находится основной файл server.js)

debuggerExtensionDll

Этот параметр определяет версию средства node-inspector, которую iisnode использует при выполнении отладки приложения Node. Сейчас для этого параметра доступны только два значения: iisnode-inspector-0.7.3.dll и iisnode-inspector.dll. По умолчанию для этого параметра задано значение iisnode-inspector-0.7.3.dll. Версия iisnode-inspector-0.7.3.dll использует node-inspector-0.7.3 и веб-сокеты. Чтобы использовать эту версию, обязательно включите веб-сокеты на веб-приложении Azure.

flushResponse

По умолчанию IIS буферизирует данные ответа до 4 МБ перед их сбросом или до окончания ответа в зависимости от того, что произойдет раньше. В iisnode предлагается параметр конфигурации для переопределения этого поведения: чтобы сбросить фрагмент тела сущности ответа, как только iisnode получит его от node.exe, вам нужно установить для атрибута iisnode/@flushResponse в web.config значение true:

<configuration>
    <system.webServer>
        <!-- ... -->
        <iisnode flushResponse="true" />
    </system.webServer>
</configuration>

Если вы включите очистку каждого фрагмента в тексте сущности ответа, необходимые для этого дополнительные действия снизят общую пропускную способность системы примерно на 5 % (по данным тестирования версии 0.1.13). Лучше всего применять этот параметр только для тех конечных точек, где требуется потоковая передача ответов (например, с помощью элемента <location> в файле web.config).

Кроме того, в приложениях потоковой передачи для параметра responseBufferLimit обработчика iisnode необходимо задать значение 0.

<handlers>
    <add name="iisnode" path="app.js" verb="\*" modules="iisnode" responseBufferLimit="0"/>
</handlers>

watchedFiles

Разделенный точкой с запятой список файлов, в которых отслеживаются изменения. Любое изменение файла приводит к перезапуску приложения. Каждая запись содержит необязательное имя каталога и обязательное имя файла, которые задаются относительно каталога с основной точкой входа в приложение. Подстановочные знаки можно использовать только в части имени файла. Значение по умолчанию — *.js;iisnode.yml.

СигналRecycleВключен

По умолчанию используется значение false. Этот параметр, если он включен, позволяет приложению Node подключиться к именованному каналу (переменная среды IISNODE_CONTROL_PIPE) и отправить сообщение "перезапустить". Это приведет к перезапуску процесса w3wp.

период простоя выгрузки страницы

По умолчанию для этого параметра используется значение 0, а это значит, что он отключен. Если задать значение больше нуля, iisnode будет выгружать все дочерние процессы каждые «idlePageOutTimePeriod» миллисекунд. См. документацию, чтобы понять значение термина "page out". Этот параметр полезен для приложений, которые используют большой объем памяти и могут время от времени выгружать страницы памяти на диск, чтобы освободить ОЗУ.

debugHeaderEnabled

По умолчанию используется значение false. Если изменить его на true, iisnode добавляет HTTP-заголовок ответа iisnode-debug к каждому отправленному им ответу HTTP. Значение заголовка iisnode-debug имеет формат URL-адреса. Некоторые элементы диагностических данных можно извлечь из фрагмента URL-адреса, а для более детальных сведений вы можете открыть URL-адрес в веб-браузере.

включение ведения логов

Этот параметр управляет ведением журналов stdout и stderr с помощью iisnode. Обработчик iisnode собирает данные stdout и stderr из процессов Node, которые он запускает, и записывает их в каталог, указанный в параметре "logDirectory". Когда этот параметр включен, приложение записывает журналы в файловую систему, а производительность приложения будет зависеть от объема собранных приложением данных.

devОшибкиВключены

По умолчанию используется значение false. Если изменить его на true, iisnode отобразит в браузере код состояния HTTP и код ошибки Win32. Код Win32 полезен при отладке определенных типов проблем.

debuggingEnabled (не включайте этот параметр на активном рабочем сайте)

Этот параметр определяет функцию отладки. В iisnode интегрировано средство node-inspector. Включение этого параметра активирует отладку приложения Node. При первом запросе отладки для вашего Node.js-приложения обработчик iisnode создает файлы node-inspector в каталоге debuggerVirtualDir после включения этого параметра. Средство node-inspector можно загрузить, отправив запрос по адресу http://yoursite/server.js/debug. С помощью параметра debuggerPathSegment можно управлять сегментом URL-адреса отладки. По умолчанию для параметра debuggerPathSegment установлено значение 'debug'. Можно задать для debuggerPathSegment, например, значение GUID, так что его будет сложнее обнаружить.

Дополнительные сведения об отладке см. в статье Отладка приложений Node.js в Windows.

Сценарии, рекомендации и устранение неполадок

Мое приложение Node отправляет слишком много исходящих вызовов

В рамках своих регулярных операций многие приложения хотят установить исходящие подключения. Например, при получении запроса для его обработки приложению Node потребуется связаться с REST API и получить необходимые для этого сведения. Следует использовать агент поддержания соединения при вызовах HTTP или HTTPS. При выполнении этих исходящих вызовов в качестве активного агента можно использовать модуль agentkeepalive.

Модуль agentkeepalive обеспечивает многократное использование сокетов на виртуальной машине Azure для вашего веб-приложения. Если для каждого исходящего запроса создается новый сокет, нагрузка на приложение возрастает. Применив в приложении механизм повторного использования сокетов для исходящих запросов, вы сможете избежать превышения допустимого числа сокетов (параметр maxSockets), выделяемых для каждой виртуальной машины. В Службе приложений Azure рекомендуется установить параметр maxSockets для agentKeepAlive со значением 128 сокетов на виртуальную машину, что соответствует 4 экземплярам node.exe, умноженным на 32 maxSockets на экземпляр.

Пример конфигурации модуля agentKeepALive:

let keepaliveAgent = new Agent({
    maxSockets: 32,
    maxFreeSockets: 10,
    timeout: 60000,
    freeSocketTimeout: 300000
});

Приложение Node потребляет слишком много ресурсов ЦП

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

Профилирование приложения Node в службе приложений Azure с помощью средства V8-Profiler

Например, предположим, что у вас есть приложение Hello World, для которого необходимо выполнить профилирование, следующим образом:

const http = require('http');
function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    WriteConsoleLog();
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Чтобы перейти на сайт консоли отладки для вашего приложения, выберите Инструменты разработки, затем >, потом выберите Перейти. В Kudu выберите консоль отладки для CMD или PowerShell.

Перейдите в каталог site/wwwroot. Здесь вы увидите интерфейс командной строки, как показано в следующем примере.

Запустите команду npm install v8-profiler.

Эта команда устанавливает v8-profiler и все его зависимости в каталоге node_modules. Далее, чтобы выполнить профилирование приложения, измените файл server.js.

const http = require('http');
const profiler = require('v8-profiler');
const fs = require('fs');

function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    profiler.startProfiling('HandleRequest');
    WriteConsoleLog();
    fs.writeFileSync('profile.cpuprofile', JSON.stringify(profiler.stopProfiling('HandleRequest')));
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Предыдущий код профилирует функцию WriteConsoleLog, а затем записывает вывод профиля в файл profile.cpuprofile, расположенный в каталоге вашего сайта wwwroot. Отправьте запрос в приложение. Вы видите, что под каталогом wwwroot вашего сайта создан файл profile.cpuprofile.

Загрузите этот файл и откройте его с помощью средств Chrome (клавиша F12). Нажмите клавишу F12 в Chrome, а затем выберите вкладку Профили и нажмите кнопку Загрузить. Выберите загруженный файл profile.cpuprofile. Щелкните на профиль, который вы только что загрузили.

Можно увидеть, что на работу функции WriteConsoleLog ушло 95 % времени. В выходных данных вы также увидите точные номера строк и исходные файлы, которые вызывают проблему.

Чрезмерное потребление памяти приложением Node

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

Обнаружение утечек и Heap Diff для Node.js

Чтобы обнаружить утечки памяти, можно использовать node-memwatch . Установите средство memwatch так же, как и v8-profiler, и измените код, чтобы снимать и сравнивать кучи для выявления утечек памяти в приложении.

Случайное завершение работы моих процессов node.exe

Node.exe может завершать работу случайным образом по нескольким причинам.

• В вашем приложении выбрасываются неперехваченные исключения – Проверьте файл d:\home\LogFiles\Application\logging-errors.txt для получения информации о выброшенных исключениях. В этом файле содержится трассировка стека, которая помогает отлаживать и исправлять приложения.
• Приложение потребляет слишком много памяти, и это мешает запустить другие процессы. Когда используемый объем памяти виртуальной машины приближается к 100 %, диспетчер процессов может завершить работу файла node.exe. Диспетчер процессов останавливает некоторые процессы, чтобы остальные получили возможность выполнить свою работу. Чтобы устранить эту проблему, выполните профилирование приложения для поиска утечек памяти. Если приложение требует большого объема памяти, используйте виртуальную машину более высокого уровня (чтобы увеличить доступный объем памяти).

Ошибка запуска приложения Node

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

• Файл node.exe находится в неправильном расположении. Проверьте параметр nodeProcessCommandLine.
• Основной файл сценария находится в неправильном расположении. Проверьте файл web.config и убедитесь, что в разделе обработчиков задано соответствующее имя основного файла сценария.
• Используется неправильная конфигурация файла web.config. Проверьте имена и значения параметров.
• Холодный запуск. Приложение запускается слишком долго. Если ваше приложение занимает больше времени, чем (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 секунд, приложение iisnode возвращает ошибку 500. Чтобы предотвратить превышение времени ожидания iisnode и возвращение ошибки с кодом 500, увеличьте значения этих параметров, чтобы они соответствовали времени запуска вашего приложения.

Сбой приложения Node

В вашем приложении выбрасываются неперехваченные исключения – проверьте файл d:\\home\\LogFiles\\Application\\logging-errors.txt, чтобы получить подробную информацию об этих исключениях. В этом файле содержится трассировка стека, которая помогает диагностировать и исправлять приложения.

Запуск приложения Node занимает слишком много времени (холодный запуск)

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

• Попробуйте выполнить отложенную загрузку node_modules и не загружать все модули при запуске приложения. Чтобы использовать отложенную загрузку модулей, выполняйте вызов require('module'), только когда модуль становится фактически нужен в функции, то есть перед первым выполнением кода модуля.
• В службе приложений Azure используется функция "локальный кэш". С помощью этой функции можно скопировать содержимое сетевой папки на локальный диск виртуальной машины. Так как файлы расположены локально, загрузка node_modules происходит значительно быстрее.

Статус и подстатус HTTP для iisnode

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

Включите FREB для приложения, чтобы просмотреть код ошибки Win32 (убедитесь, что вы включите FREB только на непроизводственных сайтах по соображениям производительности).

NODE.exe поддерживает параметр с именем NODE_PENDING_PIPE_INSTANCES. В службе приложений Azure для этого параметра задано значение 5000. Это означает, что файл node.exe в именованном канале может принять 5000 запросов за раз. Этого достаточно для большинства приложений Node, запущенных в службе приложений Azure. Вы не должны видеть код 503.1003 в службе приложений Azure из-за высокого значения NODE_PENDING_PIPE_INSTANCES.

Связанный контент

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

• Приступая к работе с веб-приложениями Node.js в службе приложений Azure
• Отладка веб-приложения Node.js в службе приложений Azure
• Использование модулей Node.js с приложениями Azure
• Azure App Service Web Apps: Node.js (Веб-приложения службы приложений Azure: Node.js)
• Центр разработчика Node.js
• Exploring the Super Secret Kudu Debug Console (Обзор сверхсекретной консоли для отладки Kudu)

Отказ от ответственности за контакт с третьими лицами

Корпорация Майкрософт предоставляет контактные данные сторонних производителей в целях получения дополнительных сведений по данной теме. Эти контактные данные могут изменяться без уведомления. Корпорация Майкрософт не гарантирует точность контактных данных сторонних производителей.