Ещё из интересного, недавно увидел что ведутся работы по поддержке Rspack в Next.js - https://github.com/vercel/next.js/blob/canary/packages%2Fnext-plugin-rspack%2FREADME.md

С одной стороны прямая конкуренция Turbopack, с другой - дешёвая возможность сильно улучшить жизнь пользователям с Webpack.

Мы в свою очередь потихоньку рефакторим @tramvai/cli сразу для двух оптимизаций:
- вынести сборщики в отдельные плагины, что позволит легко сделать новый Rspack плагин
- разнести по разным воркерам текущую Webpack сборку (которая будет жить ещё долго), так как multi compiler сборка вебпака для серверного и клиентского кода сильно конкурирует между собой в одном Node.js процессе

Привет!

Одной из недавних больших задач была интеграция Opentelemetry в Tramvai - https://tramvai.dev/docs/features/monitoring/telemetry

Экосистема вокруг Opentelemetry очень развитая, крутая документация, есть SDK под разные ЯП, для Node.js множество интеграций под всевозможные фреймворки и встроенные модули.

Основной рекомендуемый подход к интеграции телеметрии - подключить авторинструментарий, который все сделает за нас, и настроить экспорт трейсов в коллектор.

Меня в этой экосистеме смутили несколько вещей:

Повсеместное использование синглтонов (не самый лучший паттерн для Node.js по ряду причин) - общие сущности составляющие ядро телеметрии (Trace, Context и тд) - создаются под капотом как глобальные переменные, хотя Async Local Storage позволяет легко этого избежать (и он уже используется для контекста).

С этим пришлось смириться, даже создавая свой экземпляр трейсера, ряд кейсов по другому не решить, надо использовать синглтоны trace / context.

Автоинструментарий особенно интересен:
- тянет несколько десятков модулей, в рантайме определяется какой из них использовать если стоит соответствующая либа и так далее (это конфигурируется)
- большая часть автоинструментария работает по принципу манкипатчинга - за исключением к примеру Fastify где есть конкретный механизм расширения, хуки
- множество бесполезных спанов - если брать Fastify, каждый хук оборачивается в спаны, зачем нам вся эта информация в трейсах?

Манкипатчинг в Node.js экосистеме для встроенных модулей - к сожалению наша реальность, хрупкая но единственная возможность мониторить к примеру исходящие запросы, dns lookups и так далее.

Тут отойду в сторону и отмечу что крутая инициатива Deno по встроенной телеметрии - https://docs.deno.com/runtime/fundamentals/open_telemetry/

А также интересная архитектура в Undici которая расширяемая из коробки в отличие от http.request - https://blog.platformatic.dev/http-fundamentals-understanding-undici-and-its-working-mechanism

И автоинструментарий для Undici к примеру без манкипатчинга а слушает конкретные события, ссылка на исходники. Хотя тут интересно что события по сути отладочные, используется diagnostic_channel.

Манкипатчинг еще ведет к такой особенности, что подключать автоинструментарий надо раньше чем весь остальной код приложения.

Рекомендуемый подход - создать отдельный файл с интеграцией автоинструментария, запустить его до сервера:

node --require ./instrumentation.js app.js

Что тоже мне не хотелось бы заставлять делать пользователей фреймворка.
При этом у нас уже есть манкипатчинг некоторых модулей для серверных метрик, и все работает без таких приседаний.

В итоге я пришел к нескольких принципам при создании интеграции:
- хочу отдельный модуль, который работает при подключении без дополнительных действий
- модуль не использует автоинструментарий, самостоятельно покрываю базовый функционал телеметрией по Semantic Conventions
- делаю удобный трейсер, его и всю конфигурацию храню в DI контейнере

Сделать кастомный Tracer оказалось не сложно, есть отличный пример у Next.js которые в свою очередь подсмотрели у Datadog:
- https://github.com/DataDog/dd-trace-js/blob/59e9a2a75f4256755b4e6c9951a0bdf8d39b4015/index.d.ts#L9
- https://github.com/vercel/next.js/blob/9a1cd356dbafbfcf23d1b9ec05f772f766d05580/packages/next/src/server/lib/trace/tracer.ts#L74

API трейсера получилось такого вида, и инкапсулирует очень бойлерплейтный код Opentelemetry:

tracer.trace('trace-name', { ...spanParameters }, async (span) => { ... });

Ключевой момент, что любую операцию надо обернуть в этот асинхронный коллбэк, для поддержки вложенного контекста (который как раз реализован через Async Local Storage), что бы каждый новый span получал родительский спан из контекста выше, и они автоматически будут выстроены в цепочку при анализе трейсов:

root span
  - child span
    - nested child span

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

Допустим в Fastify есть хук onRequest, который в коллбэке передает нам метод done - он содержит весь стек вызовов на обработку текущего запроса, и весь запрос легко обернуть в спан:

app.addHook('onRequest', (req, reply, done) => {
  tracer.trace('GET', async () => {
    done();
  })
})

Но в Tramvai есть базовые механизмы, которые мы тоже хотим мониторить:
- линии Command Line Runner
- значимые хуки роутера
- запросы через наши Http Client

И это привело меня к необходимости изменения архитектуры этих механизмов, и в целом выбрать подход куда двигаться базовым модулям Tramvai.

Я рассматривал два основных варианта как референс - хуки Fastify, и хуки Webpack Tapable, на последнем варианте в итоге и остановился.

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

Примеры Tapable хуков можно посмотреть в юнит-тесте - https://github.com/tramvaijs/tramvai/blob/main/packages/libs/hooks/src/tapable.spec.ts

Отрефакторил Command Line Runner, Router, Http Client interceptors, тут сразу подсвечу мою недоработку которая может в будущем выстрелить - стоило сделать подмену реализаций (выбор старой или новой реализации) через параметры сборки, я же просто создал копии файлов, отрефакторил и переключил старый на новый хардкодом, прогнав все тесты.

Это позволило сделать простой кастомный автоинструментарий, состоящий из оборачивания подходящих Tapable хуков, пример с роутингом - https://github.com/tramvaijs/tramvai/blob/f9d7bde4991b07689b95347efd64b9eea17b59b8/packages/modules/opentelemetry/src/instrumentation/router.ts#L34

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

И конечно тут не без значимых минусов:
- хуки и особенно оборачивание (через метод wrap) раздувает стек вызовов JS кода, заметно усложняет отладку
- также это незначительно, но влияет на перформанс, но тут заметнее влияние на создание большого количества спанов (повод не делать их слишком много и не мониторить мелкие задачи)
- хуки усложняют код, делают поведение не линейным и менее прозрачным - сделал для всех хуков описание и визуализацию - https://tramvai.dev/docs/features/app-lifecycle#commandlinerunner-hooks

В итоге уже время и практика использования покажет, насколько было верное решение)

Еще из небольших но интересных вещей по телеметрии:
- для сквозного поиска между трейсами и логами добавил корреляцию для логов, достаю из асинхронного контекста id'шники спанов и трейсов и добавляю в каждый лог
- для сквозного поиска между разными сервисами добавил всплытие контекста - учитываю id'шники спанов и трейсов из заголовков входящего запроса на сервер, добавляю соответствующие заголовки в исходящие HTTP запросы

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

Постарался вернуть как было, а если будет проблема со спамом, спрошу вашего совета как решаете в своих каналах)

Привет!

Как-то писал про серверные оптимизации ноды, и в частности про параметр --max-semi-space-size - https://t.me/super_oleg_dev/115

Часто появляются новые кейсы которые показывают сколько же нюансов в работе GC ноды.

Например, не так давно коллеги разбирались с частыми OOM рестартами приложения.

Оказалось, что в условиях ограниченных k8s лимитов, у этого приложения дефолтные значения --max-old-space-size были выше или примерно равны лимиту по памяти для подов этого приложения.

Чем больше параметр, тем меньше времени GC тратит на очистку неиспользуемой памяти при ее низком потреблении, что при выделенных 512mb памяти на под, и max-old-space-size размером в 1gb, позволит накопиться мусору и приведет к OOM.

Также, этот параметр не ограничивает все потребление памяти Node.js процессом, а только ее часть, то есть даже при выделенных 1gb памяти на под, значение max-old-space-size должно быть ниже 1gb, иначе приведет к OOM.

Хорошо написано про параметр в этом документе, предлагают ставить max-old-space-size примерно в 75% от доступной памяти - https://github.com/goldbergyoni/nodebestpractices/blob/master/sections/docker/memory-limit.md

Сегодня разбирался с обратной проблемой.

У приложения большое потребление памяти, долго работает GC, высокий лаг event loop.

Обнаружил что у коллег все стало сильно хуже когда подняли --max-old-space-size с 2gb до 4gb.

Погонял приложение локально, даже с кэшами ему нужно памяти сотни мегабайт, но никак не гигабайты. Правда важно учесть нюанс, что SSR запросы на больших страницах дорогие и по памяти, это могут быть мегабайты строк (HTML, стейт и прочее) в памяти на каждый запрос и конечно тут нужно иметь запас на случай нагрузок.

Еще раз погонял нагрузки на приложении уже с увеличенным --max-old-space-size, и увидел что сильно поднимается пиковое потребление памяти, 1-2 гигабайта легко, которые потом очищаются до пары сотен мегабайт.

Как это работает:
- приложению выделено слишком много памяти
- GC работает реже
- потребление памяти быстро повышается (на продакшене постоянные стабильные нагрузки)
- и тут GC начинает медленно работать, особенно заметно на major очистках!

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

Теперь я хочу исследовать поподробнее, хорошая ли наша базовая рекомендация повышать дефолты --max-semi-space-size, так как этот параметр ведет к еще более заметному накоплению памяти между очистками, и будет ли корреляция с разными значения --max-old-space-size (хотя отвечают они за разные участки памяти, и на метриках по идее от изменения первого параметра я должен увидеть влияние на GC minor, а от второго на GC major).

И тут легко попасть в ситуацию, когда увеличение работы которую нужно сделать GC не компенсируется уменьшением частоты работы GC.

Что я собственно и увидел в сегодняшнем кейсе c повышенным значением --max-old-space-size, где GC и major и minor работать стали реже в два раза, но тяжелее чуть ли не в десяток раз (прикладываю графики)

Привет!

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

Есть такая либа day.js, и ее система плагинов - https://day.js.org/docs/en/plugin/plugin

В этой документации рекомендованный подход к расширению - перезапись прототипа класса dayjs:

// overriding existing API
// e.g. extend dayjs().format()
const oldFormat = dayjsClass.prototype.format

dayjsClass.prototype.format = function(arguments) {
  // original format result
  const result = oldFormat.bind(this)(arguments)
  // return modified result
}



У приложения - своя обертка над day.js где как раз есть такой плагин, перезаписывающий метод прототипа.

Далее, что мы имеем:
- эта обертка и сам day.js вынесены в shared Module Federation чанк
- хостовое приложение поставляет этот чанк
- в приложении загружается код микрофронта, который использует этот чанк

Код микрофронта имеет такой жизненный цикл на сервере:
- загружаем код микрофронта как строку
- компилируем строку и получаем JS модуль с экспортами
- сохраняем этот модуль в LRU кэш (микрофронтов может быть много, новые версии появляются, старые становятся не нужны)
- инициализируем Module Federation

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

После долгой отладки мы обнаружили, что:
- код микрофронта в какой-то момент вытесняется из кэша и загружается заново
- код микрофронта инициализируется и вызывает shared модуль - обертку над day.js, что бы получить его экспорты
- shared модуль переиспользуется тот же самый, но заново выполняется код плагина через dayjs.extend(plugin)

Только на этом вызове, метод в прототипе const oldFormat = dayjsClass.prototype.format - это уже тот метод, который один раз мы заманкипатчили на предыдущем вызове плагина!

В итоге на каждое вытеснение микрофронта из кэша мы получаем матрешку перезаписи метода в прототипе, если визуализировать это в псевдокоде:

dayjsClass.prototype.format = myFnc
- dayjsClass.prototype.format = myFnc(myFnc)
  - dayjsClass.prototype.format = myFnc(myFnc(myFnc))
    - dayjsClass.prototype.format = myFnc(myFnc(myFnc(myFnc)))
      ...

Наглядный кейс про сайд-эффекты, shared зависимости и синглтоны.

Что осталось не до конца понятным - как именно утекает ссылка на исходники микрофронта в контекст условной myFnc в коде shared чанка.

Пример как выглядит в самом начале ссылка на утекающий код в профайлере.

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

Часто в интернетах пишут про NODE_COMPILE_CACHE и ускорение скриптов.

Но добавляю к скрипту который запускает webpack сборку небольшого example приложения (соответственно считывает просто кучу модулей по пути, в том числе babel, его плагины и тд), и вижу либо отсутствие изменений либо ухудшение (штраф за формирование этого кэша).

При отладке через NODE_DEBUG_NATIVE=COMPILE_CACHE, логи показывают успешное переиспользование кэша.

У кого-нибудь есть успешный опыт интеграции NODE_COMPILE_CACHE?

Также, пока писал пост понял что при сборе CPU profile в Node.js не вижу сколько эта компиляция в принципе занимает времени, в отличие от обычной performance вкладки в девтулзах клиентских приложений, где есть время Compile code / Compile script. Можно ли это собрать для Node.js скрипта?

И раз уж зашел разговор о CLI, поделюсь одной из актуальных задач - разработка обновленной @tramvai/cli (уже писал про это короткий пост)

Во вложении - дизайн новой CLI, он уже претерпел ряд изменений, но основные концепции остались.

Какие основные цели для новой CLI:
- решить базовые проблемы с перформансом - основная, webpack MultiCompiler запускает все сборки в одном процессе, серверная и клиентская конкурируют между собой
- реализовать удобную систему плагинов (и первым же новым плагином интегрировать rspack)
- полностью разделить JS API и CLI API
- сделать общий набор тест-кейсов, который будет удобно запустить с разными плагинами - вебпак+бабель, вебпак+swc, rspack
- избавиться от легаси, улучшить отладку, упростить структуру

Итак, основная техническая задачка тут - ускорение двух параллельных вебпак сборок.

Тут очевидное решение - вынести их в worker_threads, что из коробки webpack и его MultiCompiler не умеет.

И главный челлендж тут - как передать конфигурацию из CLI в воркеры, если там могут быть плагины - то есть не сериализуемые методы/классы/прочие объекты?

Этот кейс решил следующим образом:
- есть общая логика - чтение tramvai.config.ts конфигурационного файла, где могут быть плагины
- есть набор входящих сериализуемых параметров, которые можно передать через CLI (`tramvai start ...`) или JS API (`new Tramvai().start(...)`)
- и основной процесс и webpack воркер - считывают один и тот же конфигурационный файл
- входящие параметры пробрасываются при старте воркера из основного процесса

Вокруг воркеров сделал небольшие удобные обертки для контроля и коммуникации.

Основной пакет @tramvai/api определяет базовые интерфейсы - DevServer и Builder, ждет их в DI контейнере, и запускает их жизненный цикл.

Вся логика с webpack, реализация DevServer на основе webpack-dev-middleware и соответствующие зависимости - в отдельном @tramvai/cli-plugin-webpack плагине, аналогичный будет для rspack.

Все babel зависимости и фабрика babel конфига - в отдельном @tramvai/cli-plugin-babel, и соответственно такой же будет для swc.

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

Похоже основным челленджем далее будет - миграция пользователей и временная поддержка двух реализация команды tramvai start.

Привет!

Достаточно давно делился статьей где описывал различные механизмы и подходы которые мы применяем для SSR приложений на Tramvai (сейчас доступна на хабре).

Один из механизмов - Request Limiter, модуль который ограничивает количество параллельно обрабатываемых запросов при перегруженном Event Loop приложения, для возможности стабильно отдавать 2xx ответы и рендерить странички даже под большими нагрузками.

Работает по похожим принципам с https://github.com/fastify/under-pressure, только не отбрасывает все запросы при нагрузке, а держит еще LIFO очередь что бы обеспечить большее количество успешных ответов без сильной деградации времени ответа.

Когда переводили наши интеграционные тесты на 20 версию Node.js, начали падать нагрузочные тесты Request Limiter. Основная проблема - перестали быстро отвечать health-чеки приложения (а отзывчивые health-чеки и метрики очень важны и что бы в реальном времени понимать что происходить и для graceful рестартов и так далее)

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

Завел issue, получил много интересного и ценного фидбека от Matteo Collina - https://github.com/nodejs/node/issues/57364

Оказалось, что изменения в libuv убрали запуск таймеров в начале цикла на старте event loop, теперь они запускаются только в конце - то есть после poll (входящие запросы и прочее) и check (setImmediate).

В веб-сервере под капотом Tramvai мы испольуем setImmediate для того что бы иметь возможность "разорвать" event loop между тяжелыми задачами по SSR и ответить на легкие запросы /metrics, /health и так далее.

У libuv есть логика по ограничению одновременно обрабатываемых immediate коллбэков - https://github.com/libuv/libuv/blob/49b6e4db0cfc2bdb4c4151030618981c2fc0795b/src/unix/core.c#L462-L465

http модуль внутри использует различные таймеры/интервалы, до обновления ноды все это вместе с request limiter работало так скажем в гармонии, логика по обработке запроса (в том числе таймеры) выполнялась на одной фазе event loop до immediate коллбэков.

После обновления libuv в Node.js, если я все правильно понял, логика обработки запроса теперь раскидана до и после check фазы с immediate коллбэками, и происходит что-то вроде взаимной блокировки - мы не можем полноценно обрабатывать новые запросы (в том числе быстро ответить 429 кодом) пока в очереди есть много immediate коллбэков.

Также Маттео накинул несколько кейсов почему в целом опасно использовать setImmediate для дробления обработки запросов и что это просаживает перф - https://github.com/fastify/fastify/pull/545

Проблем тут вижу несколько:
- в нашем кейсе, SSR это не тысячи а десятки RPS как в бенчмарках fastify/h3, и такие проблемы нам не важны
- но при этом у нас была реальная и очень полезная возможность оставаться отзывчивыми, и держать под нагрузкой адекватные 2xx RPS
- также я не вижу интеграционных тестов в репозитории under-pressure и сомневаюсь до конца что инструмент работает ожидаемо

Пару дней назад Маттео написал даже в блок Platformatic (это их коммерческий продукт для Node.js стека) про кейс, итого получился подробный обзор проблемы (правда черезчур нейросетевой):
- https://x.com/matteocollina/status/1951322487595090177?s=19
- https://blog.platformatic.dev/the-dangers-of-setimmediate

Основной поинт Маттео который я полностью поддерживаю - надо использовать worker_threads, и само приложение поднимать в воркере, таким образом изолировать его event loop (тут он рекламирует их сервер Watt который так делает из коробки)

Для Tramvai тут проблема что это сильно не вписывается в текущую архитектуру.

Придется делать еще один заход и смотреть как мы можем избавиться от setImmediate, и что в итоге выжать из Request Limiter под нагрузками на свежих версиях Node.js