[Node.JS, Разработка веб-сайтов] Мониторинг Node.js-приложения
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Здравствуйте! Меня зовут Ренат Саматов, я возглавляю фронтенд-направление в линейке продуктов Витрина. Большая часть наших проектов рендерится на сервере. Сегодня мы побеседуем об одном из важнейших аспектов SSR-приложения: о мониторинге.
Даже в 2020-м мониторинг Node.js-приложения является непростой задачей. Node.js однопоточный язык программирования и работает с динамической типизацией. Интерпретатору и среде исполнения предоставлены широкие полномочия, что очень легко может привести к утечки памяти или высокой нагрузке на процессор. Node.js работает асинхронно (псевдопараллельно), однако если одна функция блокирует поток или очередь событий, производительность приложения начинает сильно проседать.
В этой статье я расскажу о том, как контролировать ваше Node.js-приложение и быть уверенным в том, что проблем с утечкой памяти, ресурсов процессора и блокировкой потока не возникает. Мы побеседуем об управлении производительностью приложения (Application Performance Management, APM) и метриках, на которые следует обращать внимание. Погнали!
Мониторинг — это систематическое наблюдение и анализ прогресса и качества. Мониторинг приложения в первую очередь необходим для того, чтобы убедиться, как ни странно, в корректной работе приложения. Вы ведь хотите узнавать о багах раньше, чем они всплывут у конечного пользователя? Или быть готовым к горизонтальному масштабированию приложения до того, как оно перестало отвечать?
Мониторинг помогает не потерять клиентов и, что особенно важно, не тратить время зря. Время — деньги, а предотвращение простоев, потери ресурсов и избавление вашего продукта от проблем с производительностью сэкономит вам деньги в долгосрочной перспективе; что и должно быть в центре внимания каждого бизнеса — зарабатывать деньги.
APM — стандартизированный способ мониторинга производительности и доступности вашего приложения, демонстрирующий диаграммы с количеством запросов, временем ответа, загрузкой CPU и использованием памяти. На этих диаграммах отображены средние значения, процентили и любые настраиваемые группы. Вы можете легко добавить APM в свое Node.js-приложение с помощью интеграции Sematext (или любого аналогичного решения) для Node.js.
Давайте подробнее рассмотрим метрики, которые необходимо отслеживать.
Метрики использования ЦП для Node.js
Выше я упоминал, что среда выполнения Node.js имеет ограничения в использовании потоков ЦП. Причиной этого является единственный поток среды выполнения, то есть он привязан к одному ядру процессора. Один экземпляр приложения Node.js может использовать только одно ядро ЦП.
Поэтому Node.js-приложения редко используют большое количество процессорного времени. Вместо этого они полагаются на неблокирующий ввод-вывод. ЦП не должен ждать запросы ввода-вывода, вместо этого он обрабатывает их асинхронно. Если вы столкнулись с высокой загрузкой ЦП, это может означать, что большая синхронная работа перегружает его и блокирует поток. Это плохо! При блокировке потока блокируются и асинхронные процессы.
В большинстве случаев вам не нужно беспокоиться о загрузке процессора. Чтобы снизить его использование, вы можете создать дочерние процессы, или форки, для обработки задач, интенсивно использующих ЦП. Например, у вас есть веб-сервер, который обрабатывает входящие запросы. Чтобы избежать блокировки этого потока, вы можете создать дочерний процесс для обработки задачи, интенсивно использующей процессор. Довольно круто.
Исправление кода с интенсивным использованием ЦП — это первый шаг к повышению производительности и стабильности вашего Node.js-сервера. Метрики, на которые следует обратить внимание:
- Использование процессора
- Загрузка процессора
Метрики использования памяти и утечек для Node.js
Чтобы разобраться в использовании памяти и возможных утечках, вам сначала нужно понять, что такое куча и стек. Значения могут храниться либо в стеке, либо в куче. Стек можно визуально представить как стопку книг, где книги на самом деле являются функциями, а их контекст сохраняется в памяти. Куча — это большая область, в которой хранится всё, что распределяется динамически.
С этим связан важный факт о памяти процесса Node.js, про который вы должны знать. Максимальный размер кучи для одного процесса может составлять 1,5 ГБ. Вы угадали! Утечки памяти — распространенная проблема в Node.js. Они случаются, когда на объекты ссылаются слишком долго, то есть значения сохраняются, даже если они не нужны. Поскольку Node.js основан на движке V8, он использует сборку мусора для освобождения памяти, используемой переменными, которые больше не нужны. Этот процесс останавливает выполнение программы. Мы поговорим о сборке мусора более подробно в следующем разделе.
Заметить утечки памяти проще, чем вы думаете. Если память вашего процесса постоянно растет, не уменьшаясь периодически за счет сборки мусора, скорее всего, у вас есть утечка памяти. Вам следует обратить внимание на следующие показатели:
- Освобожденная память между циклами сборки мусора.
- Объем выделенной под процесс памяти.
- Использование выделенной памяти процессом.
Метрики сборки мусора для Node.js
В среде выполнения V8 сборка мусора останавливает выполнение программы. Есть два типа сборки мусора. Один из них называется очисткой и использует циклы инкрементной сборки мусора для обработки только части кучи за раз. Это очень быстро по сравнению с полными циклами сборки мусора, которые освобождают память от объектов и переменных, переживших несколько циклов добавочной сборки мусора. Поскольку полные циклы сборки мусора приостанавливают выполнение программы, они выполняются реже.
Измеряя частоту выполнения полного или инкрементного цикла сборки мусора, вы можете увидеть, как он влияет на время, необходимое для освобождения памяти, и на то, сколько памяти было освобождено. Сравнение освобожденной памяти с размером кучи может показать вам, есть ли растущая тенденция, которая заставит вас выяснить, есть ли у вас утечка памяти.
Из-за всего упомянутого выше вам следует отслеживать следующие показатели сборки мусора Node.js:
- Время, затраченное на сборку мусора.
- Счетчики полных циклов сборки мусора.
- Счетчики дополнительных циклов сборки мусора.
- Освобожденная память после сборки мусора.
Показатели цикла событий Node.js
Node.js быстр, потому что он может обрабатывать события асинхронно. Это реализовано благодаря циклу событий: специальному месту, зарезервированному для обработки асинхронных функций, которые вызываются как ответы на определенные события и выполняются вне основного потока. Такие функции также называются функциями обратного вызова.
Node.js может быть привязан к ЦП и использовать асинхронные операции, чтобы не тратить циклы процессора во время ожидания операций ввода-вывода. Сервер может обрабатывать огромное количество подключений и не блокироваться для операций ввода-вывода. Это так и называется: неблокирующий ввод-вывод. Однако цикл событий может замедлиться, и в конечном итоге приведет к тому, что каждое последующее событие будет обрабатываться дольше, то есть возникнет так называемая задержке цикла событий.
Распространенными причинами запаздывания цикла событий являются длительные синхронные процессы и постепенное увеличение количества задач на цикл.
Длительные синхронные процессы
Помните, как вы обрабатываете синхронное выполнение в своем приложении? Все остальные операции должны дождаться выполнения. Отсюда знаменитое правило производительности Node.js: не блокируйте цикл событий! Вы не можете избежать работы вашего сервера, связанной с процессором, но вы можете понять, как выполнять асинхронные и синхронные задачи. Как упоминалось выше, для синхронных задач используйте форки (дочерние процессы).
Постепенное увеличение количества задач на цикл
По мере масштабирования приложения вы увидите увеличение нагрузки и количества задач на цикл. Node.js отслеживает все асинхронные функции, которые должны обрабатываться циклом событий. Задержка, возникающая при увеличении количества задач, приведет к увеличению времени отклика, когда количество станет слишком большим.
Хорошая новость заключается в том, что вы можете облегчить ситуацию, увеличив количество процессов, выполняющих ваше приложение. Используя модуль кластера, вы можете задействовать все ядра ЦП сервера.
Поэтому необходимо отслеживать показатели:
- Самая медленная обработка событий (максимальная задержка).
- Самая быстрая обработка событий (минимальная задержка).
- Средняя задержка цикла событий.
Node.js в кластерном режиме и разветвление рабочих процессов
До сих пор я несколько раз упоминал об однопоточном характере Node.js, об ограничении памяти для одного процесса и о том, что блокировки потока следует избегать всеми способами. Помимо этого масштабирование Node.js выполняется с помощью кластерного модуля.
Используя модуль кластера, вы можете создать главный процесс, который разделяет сокеты с разветвленными рабочими процессами. Эти процессы могут обмениваться сообщениями. Все разветвленные рабочие процессы имеют собственный идентификатор процесса и могут работать на выделенном ядре ЦП. Типичным вариантом использования веб-серверов является создание рабочих процессов, которые действуют в общем сокете сервера и обрабатывают запросы циклически.
Количество рабочих процессов — в том числе порожденные модулем кластера, и дочерние процессы, порожденные запуском синхронных задач вне основного потока, — может быть важной метрикой, которую необходимо знать. Если процесс по какой-то причине были прекращены, важно, чтобы вы снова запустили их. Наличие этой функции в инструменте мониторинга может быть большим преимуществом.
Здесь необходимо следить за показателями:
- Количество воркеров.
- Задержка цикла событий на одного воркера.
Node.js HTTP-запрос / задержка ответа
Следить за задержками, с которыми сталкивается пользователь, — самый важный шаг в мониторинге любого API. HTTP-запросы, попадающие на ваш сервер, и своевременные ответы пользователей — вот что заставит ваших клиентов возвращаться.
При мониторинге показателей HTTP-запросов и ответов необходимо учитывать 4 ключевых значения:
- Время отклика.
- Частоту запросов.
- Частоту ошибок.
- Размер содержимого запроса / ответа.
Резюме
Мониторинг работоспособности и производительности ваших Node.js-приложений может быть непростым. Ключевые метрики Node.js тесно связаны. Циклы сборки мусора вызывают изменения в памяти процесса и использовании ЦП. Отслеживание этих показателей Node.js имеет решающее значение для поддержания работоспособности вашего приложения и обслуживания пользователей с минимальной задержкой.
Выше приведены показатели, на которые я обращаю внимание в первую очередь. Буду рад любым вопросам и обратной связи в комментариях. В своих следующих публикациях я буду подробно освещать сценарии, связанные с мониторингом, и рассказывать о том, как мы их решаем в ДомКлике.
Спасибо за внимание.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Проектирование и рефакторинг, Разработка для Office 365, Разработка под Windows] Как скрестить Excel c интерактивным веб-приложением
- [JavaScript, ReactJS, Программирование, Разработка веб-сайтов] Мифы о useEffect (перевод)
- [Разработка веб-сайтов, JavaScript, Социальные сети и сообщества] Front End Meetup от Facebook Developer Circle: Moscow
- [Веб-дизайн, Разработка веб-сайтов, Повышение конверсии] Услышал интересное мнение по поводу лэндингов. Согласны или нет?
- [Разработка веб-сайтов, Клиентская оптимизация, Серверная оптимизация, Браузеры] А ваш CDN умеет так?
- [Разработка веб-сайтов, Python, Django] Отношение один к одному: связывание модели пользователя с кастомной моделью профиля в Django (перевод)
- [JavaScript, Программирование, Разработка веб-сайтов] Основные команды bash, git, npm и yarn, а также немного о package.json и semver
- [Laravel, PHP, Разработка веб-сайтов] Laravel–Дайджест (28 сентября – 4 октября 2020)
- [Веб-дизайн, Разработка веб-сайтов, Google Web Toolkit, Поисковая оптимизация, Голосовые интерфейсы] Современное SEO: качество страниц
- [Разработка веб-сайтов, Java] Разработка веб-приложений на встраиваемом портале
Теги для поиска: #_node.js, #_razrabotka_vebsajtov (Разработка веб-сайтов), #_node.js, #_apmmonitoring (apm-мониторинг), #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_node.js, #_razrabotka_vebsajtov (
Разработка веб-сайтов
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:41
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Здравствуйте! Меня зовут Ренат Саматов, я возглавляю фронтенд-направление в линейке продуктов Витрина. Большая часть наших проектов рендерится на сервере. Сегодня мы побеседуем об одном из важнейших аспектов SSR-приложения: о мониторинге. Даже в 2020-м мониторинг Node.js-приложения является непростой задачей. Node.js однопоточный язык программирования и работает с динамической типизацией. Интерпретатору и среде исполнения предоставлены широкие полномочия, что очень легко может привести к утечки памяти или высокой нагрузке на процессор. Node.js работает асинхронно (псевдопараллельно), однако если одна функция блокирует поток или очередь событий, производительность приложения начинает сильно проседать. В этой статье я расскажу о том, как контролировать ваше Node.js-приложение и быть уверенным в том, что проблем с утечкой памяти, ресурсов процессора и блокировкой потока не возникает. Мы побеседуем об управлении производительностью приложения (Application Performance Management, APM) и метриках, на которые следует обращать внимание. Погнали! Мониторинг — это систематическое наблюдение и анализ прогресса и качества. Мониторинг приложения в первую очередь необходим для того, чтобы убедиться, как ни странно, в корректной работе приложения. Вы ведь хотите узнавать о багах раньше, чем они всплывут у конечного пользователя? Или быть готовым к горизонтальному масштабированию приложения до того, как оно перестало отвечать? Мониторинг помогает не потерять клиентов и, что особенно важно, не тратить время зря. Время — деньги, а предотвращение простоев, потери ресурсов и избавление вашего продукта от проблем с производительностью сэкономит вам деньги в долгосрочной перспективе; что и должно быть в центре внимания каждого бизнеса — зарабатывать деньги. APM — стандартизированный способ мониторинга производительности и доступности вашего приложения, демонстрирующий диаграммы с количеством запросов, временем ответа, загрузкой CPU и использованием памяти. На этих диаграммах отображены средние значения, процентили и любые настраиваемые группы. Вы можете легко добавить APM в свое Node.js-приложение с помощью интеграции Sematext (или любого аналогичного решения) для Node.js. Давайте подробнее рассмотрим метрики, которые необходимо отслеживать.  Метрики использования ЦП для Node.js Выше я упоминал, что среда выполнения Node.js имеет ограничения в использовании потоков ЦП. Причиной этого является единственный поток среды выполнения, то есть он привязан к одному ядру процессора. Один экземпляр приложения Node.js может использовать только одно ядро ЦП. Поэтому Node.js-приложения редко используют большое количество процессорного времени. Вместо этого они полагаются на неблокирующий ввод-вывод. ЦП не должен ждать запросы ввода-вывода, вместо этого он обрабатывает их асинхронно. Если вы столкнулись с высокой загрузкой ЦП, это может означать, что большая синхронная работа перегружает его и блокирует поток. Это плохо! При блокировке потока блокируются и асинхронные процессы. В большинстве случаев вам не нужно беспокоиться о загрузке процессора. Чтобы снизить его использование, вы можете создать дочерние процессы, или форки, для обработки задач, интенсивно использующих ЦП. Например, у вас есть веб-сервер, который обрабатывает входящие запросы. Чтобы избежать блокировки этого потока, вы можете создать дочерний процесс для обработки задачи, интенсивно использующей процессор. Довольно круто. Исправление кода с интенсивным использованием ЦП — это первый шаг к повышению производительности и стабильности вашего Node.js-сервера. Метрики, на которые следует обратить внимание:
Метрики использования памяти и утечек для Node.js Чтобы разобраться в использовании памяти и возможных утечках, вам сначала нужно понять, что такое куча и стек. Значения могут храниться либо в стеке, либо в куче. Стек можно визуально представить как стопку книг, где книги на самом деле являются функциями, а их контекст сохраняется в памяти. Куча — это большая область, в которой хранится всё, что распределяется динамически. С этим связан важный факт о памяти процесса Node.js, про который вы должны знать. Максимальный размер кучи для одного процесса может составлять 1,5 ГБ. Вы угадали! Утечки памяти — распространенная проблема в Node.js. Они случаются, когда на объекты ссылаются слишком долго, то есть значения сохраняются, даже если они не нужны. Поскольку Node.js основан на движке V8, он использует сборку мусора для освобождения памяти, используемой переменными, которые больше не нужны. Этот процесс останавливает выполнение программы. Мы поговорим о сборке мусора более подробно в следующем разделе. Заметить утечки памяти проще, чем вы думаете. Если память вашего процесса постоянно растет, не уменьшаясь периодически за счет сборки мусора, скорее всего, у вас есть утечка памяти. Вам следует обратить внимание на следующие показатели:
Метрики сборки мусора для Node.js В среде выполнения V8 сборка мусора останавливает выполнение программы. Есть два типа сборки мусора. Один из них называется очисткой и использует циклы инкрементной сборки мусора для обработки только части кучи за раз. Это очень быстро по сравнению с полными циклами сборки мусора, которые освобождают память от объектов и переменных, переживших несколько циклов добавочной сборки мусора. Поскольку полные циклы сборки мусора приостанавливают выполнение программы, они выполняются реже. Измеряя частоту выполнения полного или инкрементного цикла сборки мусора, вы можете увидеть, как он влияет на время, необходимое для освобождения памяти, и на то, сколько памяти было освобождено. Сравнение освобожденной памяти с размером кучи может показать вам, есть ли растущая тенденция, которая заставит вас выяснить, есть ли у вас утечка памяти. Из-за всего упомянутого выше вам следует отслеживать следующие показатели сборки мусора Node.js:
Показатели цикла событий Node.js Node.js быстр, потому что он может обрабатывать события асинхронно. Это реализовано благодаря циклу событий: специальному месту, зарезервированному для обработки асинхронных функций, которые вызываются как ответы на определенные события и выполняются вне основного потока. Такие функции также называются функциями обратного вызова. Node.js может быть привязан к ЦП и использовать асинхронные операции, чтобы не тратить циклы процессора во время ожидания операций ввода-вывода. Сервер может обрабатывать огромное количество подключений и не блокироваться для операций ввода-вывода. Это так и называется: неблокирующий ввод-вывод. Однако цикл событий может замедлиться, и в конечном итоге приведет к тому, что каждое последующее событие будет обрабатываться дольше, то есть возникнет так называемая задержке цикла событий. Распространенными причинами запаздывания цикла событий являются длительные синхронные процессы и постепенное увеличение количества задач на цикл.  Длительные синхронные процессы Помните, как вы обрабатываете синхронное выполнение в своем приложении? Все остальные операции должны дождаться выполнения. Отсюда знаменитое правило производительности Node.js: не блокируйте цикл событий! Вы не можете избежать работы вашего сервера, связанной с процессором, но вы можете понять, как выполнять асинхронные и синхронные задачи. Как упоминалось выше, для синхронных задач используйте форки (дочерние процессы). Постепенное увеличение количества задач на цикл По мере масштабирования приложения вы увидите увеличение нагрузки и количества задач на цикл. Node.js отслеживает все асинхронные функции, которые должны обрабатываться циклом событий. Задержка, возникающая при увеличении количества задач, приведет к увеличению времени отклика, когда количество станет слишком большим. Хорошая новость заключается в том, что вы можете облегчить ситуацию, увеличив количество процессов, выполняющих ваше приложение. Используя модуль кластера, вы можете задействовать все ядра ЦП сервера. Поэтому необходимо отслеживать показатели:
Node.js в кластерном режиме и разветвление рабочих процессов До сих пор я несколько раз упоминал об однопоточном характере Node.js, об ограничении памяти для одного процесса и о том, что блокировки потока следует избегать всеми способами. Помимо этого масштабирование Node.js выполняется с помощью кластерного модуля. Используя модуль кластера, вы можете создать главный процесс, который разделяет сокеты с разветвленными рабочими процессами. Эти процессы могут обмениваться сообщениями. Все разветвленные рабочие процессы имеют собственный идентификатор процесса и могут работать на выделенном ядре ЦП. Типичным вариантом использования веб-серверов является создание рабочих процессов, которые действуют в общем сокете сервера и обрабатывают запросы циклически. Количество рабочих процессов — в том числе порожденные модулем кластера, и дочерние процессы, порожденные запуском синхронных задач вне основного потока, — может быть важной метрикой, которую необходимо знать. Если процесс по какой-то причине были прекращены, важно, чтобы вы снова запустили их. Наличие этой функции в инструменте мониторинга может быть большим преимуществом. Здесь необходимо следить за показателями:
Node.js HTTP-запрос / задержка ответа Следить за задержками, с которыми сталкивается пользователь, — самый важный шаг в мониторинге любого API. HTTP-запросы, попадающие на ваш сервер, и своевременные ответы пользователей — вот что заставит ваших клиентов возвращаться. При мониторинге показателей HTTP-запросов и ответов необходимо учитывать 4 ключевых значения:
Резюме Мониторинг работоспособности и производительности ваших Node.js-приложений может быть непростым. Ключевые метрики Node.js тесно связаны. Циклы сборки мусора вызывают изменения в памяти процесса и использовании ЦП. Отслеживание этих показателей Node.js имеет решающее значение для поддержания работоспособности вашего приложения и обслуживания пользователей с минимальной задержкой. Выше приведены показатели, на которые я обращаю внимание в первую очередь. Буду рад любым вопросам и обратной связи в комментариях. В своих следующих публикациях я буду подробно освещать сценарии, связанные с мониторингом, и рассказывать о том, как мы их решаем в ДомКлике. Спасибо за внимание. =========== Источник: habr.com =========== Похожие новости:
Блог компании ДомКлик ), #_node.js, #_razrabotka_vebsajtov ( Разработка веб-сайтов ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:41
Часовой пояс: UTC + 5