Только сейчас обнаружил что нельзя было оставить комментарии к постам без добавления в группу - чат, в котором я даже не знал что кто-то пытается добавиться...
Постарался вернуть как было, а если будет проблема со спамом, спрошу вашего совета как решаете в своих каналах)
Постарался вернуть как было, а если будет проблема со спамом, спрошу вашего совета как решаете в своих каналах)
👍2
Привет!
Как-то писал про серверные оптимизации ноды, и в частности про параметр --max-semi-space-size
Часто появляются новые кейсы которые показывают сколько же нюансов в работе 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 работать стали реже в два раза, но тяжелее чуть ли не в десяток раз (прикладываю графики)
Как-то писал про серверные оптимизации ноды, и в частности про параметр --max-semi-space-size
- https://news.1rj.ru/str/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 работать стали реже в два раза, но тяжелее чуть ли не в десяток раз (прикладываю графики)
🔥28❤3
Привет!
Продолжая кейс с высоким потреблением памяти, обнаружили таки утечку в приложении, и она довольно интересная.
Есть такая либа day.js, и ее система плагинов - https://day.js.org/docs/en/plugin/plugin
В этой документации рекомендованный подход к расширению - перезапись прототипа класса dayjs:
У приложения - своя обертка над day.js где как раз есть такой плагин, перезаписывающий метод прототипа.
Далее, что мы имеем:
- эта обертка и сам day.js вынесены в shared Module Federation чанк
- хостовое приложение поставляет этот чанк
- в приложении загружается код микрофронта, который использует этот чанк
Код микрофронта имеет такой жизненный цикл на сервере:
- загружаем код микрофронта как строку
- компилируем строку и получаем JS модуль с экспортами
- сохраняем этот модуль в LRU кэш (микрофронтов может быть много, новые версии появляются, старые становятся не нужны)
- инициализируем Module Federation
Проблема - код микрофронта и его скомпилированный результат многократно дублируются в памяти, при этом прослеживается очень длинный трейс - ссылка на метод dayjs.
После долгой отладки мы обнаружили, что:
- код микрофронта в какой-то момент вытесняется из кэша и загружается заново
- код микрофронта инициализируется и вызывает shared модуль - обертку над day.js, что бы получить его экспорты
- shared модуль переиспользуется тот же самый, но заново выполняется код плагина через
Только на этом вызове, метод в прототипе
В итоге на каждое вытеснение микрофронта из кэша мы получаем матрешку перезаписи метода в прототипе, если визуализировать это в псевдокоде:
Наглядный кейс про сайд-эффекты, shared зависимости и синглтоны.
Что осталось не до конца понятным - как именно утекает ссылка на исходники микрофронта в контекст условной m
Продолжая кейс с высоким потреблением памяти, обнаружили таки утечку в приложении, и она довольно интересная.
Есть такая либа 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 зависимости и синглтоны.
Что осталось не до конца понятным - как именно утекает ссылка на исходники микрофронта в контекст условной m
yFnc в коде shared чанка.day.js.org
Plugin · Day.js
A plugin is an independent module that can be added to Day.js to extend functionality or add new features.
🔥8🥴8
Часто в интернетах пишут про NODE_COMPILE_CACHE и ускорение скриптов.
Но добавляю к скрипту который запускает webpack сборку небольшого example приложения (соответственно считывает просто кучу модулей по пути, в том числе babel, его плагины и тд), и вижу либо отсутствие изменений либо ухудшение (штраф за формирование этого кэша).
При отладке через
У кого-нибудь есть успешный опыт интеграции NODE_COMPILE_CACHE?
Также, пока писал пост понял что при сборе CPU profile в Node.js не вижу сколько эта компиляция в принципе занимает времени, в отличие от обычной performance вкладки в девтулзах клиентских приложений, где есть время Compile code / Compile noscript. Можно ли это собрать для Node.js скрипта?
Но добавляю к скрипту который запускает webpack сборку небольшого example приложения (соответственно считывает просто кучу модулей по пути, в том числе babel, его плагины и тд), и вижу либо отсутствие изменений либо ухудшение (штраф за формирование этого кэша).
При отладке через
NODE_DEBUG_NATIVE=COMPILE_CACHE, логи показывают успешное переиспользование кэша.У кого-нибудь есть успешный опыт интеграции NODE_COMPILE_CACHE?
Также, пока писал пост понял что при сборе CPU profile в Node.js не вижу сколько эта компиляция в принципе занимает времени, в отличие от обычной performance вкладки в девтулзах клиентских приложений, где есть время Compile code / Compile noscript. Можно ли это собрать для Node.js скрипта?
nodejs.org
Node.js — Node.js v22.1.0 (Current)
Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and noscripts.
И раз уж зашел разговор о CLI, поделюсь одной из актуальных задач - разработка обновленной @tramvai/cli (уже писал про это короткий пост)
Во вложении - дизайн новой CLI, он уже претерпел ряд изменений, но основные концепции остались.
Какие основные цели для новой CLI:
- решить базовые проблемы с перформансом - основная, webpack MultiCompiler запускает все сборки в одном процессе, серверная и клиентская конкурируют между собой
- реализовать удобную систему плагинов (и первым же новым плагином интегрировать rspack)
- полностью разделить JS API и CLI API
- сделать общий набор тест-кейсов, который будет удобно запустить с разными плагинами - вебпак+бабель, вебпак+swc, rspack
- избавиться от легаси, улучшить отладку, упростить структуру
Итак, основная техническая задачка тут - ускорение двух параллельных вебпак сборок.
Тут очевидное решение - вынести их в worker_threads, что из коробки webpack и его MultiCompiler не умеет.
И главный челлендж тут - как передать конфигурацию из CLI в воркеры, если там могут быть плагины - то есть не сериализуемые методы/классы/прочие объекты?
Этот кейс решил следующим образом:
- есть общая логика - чтение
- есть набор входящих сериализуемых параметров, которые можно передать через 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.
Во вложении - дизайн новой 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.
🔥6👍2
Одна из классных идей в новой CLI - кастомные трейсы в формате Trace Event Format
Идея взята у Parcel, Rspack и Next.js, примеры:
- https://parceljs.org/features/profiling/#tracing
- https://github.com/parcel-bundler/parcel/blob/v2/packages/core/profiler/src/Tracer.js
- https://rspack.dev/contribute/development/tracing
Написал кастомный трейсер поверх либы chrome-trace-event, пример API:
Во вложении пример визуализации кастомного трейса на сборку и несколько ребилдов, в интерфейсе https://ui.perfetto.dev/. Очень удобно смотреть сколько времени занимают основные операции, какие блокируют друг друга, где произошла ошибка (трейсы пишутся на диск не в конце а все время жизни скрипта)
В идеале - еще собирать более подробные трейсы по сборке через хуки бандлера.
Идея взята у Parcel, Rspack и Next.js, примеры:
- https://parceljs.org/features/profiling/#tracing
- https://github.com/parcel-bundler/parcel/blob/v2/packages/core/profiler/src/Tracer.js
- https://rspack.dev/contribute/development/tracing
Написал кастомный трейсер поверх либы chrome-trace-event, пример API:
const tracer = new Tracer();
tracer.wrap({ event: 'event' }, async () => {
await doSomethingAsync();
});
Во вложении пример визуализации кастомного трейса на сборку и несколько ребилдов, в интерфейсе https://ui.perfetto.dev/. Очень удобно смотреть сколько времени занимают основные операции, какие блокируют друг друга, где произошла ошибка (трейсы пишутся на диск не в конце а все время жизни скрипта)
В идеале - еще собирать более подробные трейсы по сборке через хуки бандлера.
🔥10
Привет!
Достаточно давно делился статьей где описывал различные механизмы и подходы которые мы применяем для 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
Достаточно давно делился статьей где описывал различные механизмы и подходы которые мы применяем для 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
Хабр
Масштабирование SSR-приложений
Привет! Меня зовут Олег Драпеза, я работаю техлидом в Тинькофф в команде Coretech Frontend. Мой основной проект — SSR мета-фреймворк tramvai , на котором работают несколько десятков фронтовых...
👍16🔥12❤6
Обновляем React ещё разок если проекты в зоне риска - https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components
react.dev
Denial of Service and Source Code Exposure in React Server Components – React
The library for web and native user interfaces
👍15😁3
Интересный драфт появился в Undici (современный встроенный в Node.js клиент для запросов) - реализация паттерна Circuit Breaker - https://github.com/nodejs/undici/pull/4700/
По сути, сейчас Undici закрывает практически все кейсы, которые мы хотим видеть для эффективных серверных запросов:
- кэширование запросов
- дедупликация запросов
- ретрай запросов
- проксирование и поддержка переменных окружения http_proxy/no_proxy
- переиспользование tcp сокетов (из коробки, а с http.request для этого нужно прокидывать явно Agent с keepAlive: true)
- dns кэширование
- circuit breaker
- мониторинг/логирование через diagnostics_channel
Мы как раз активно мигрируем на
- мониторинг кэша - https://github.com/nodejs/undici/pull/4589
- мониторинг прокси - https://github.com/nodejs/undici/pull/4659
- env proxy ближе к стандарту - https://github.com/nodejs/undici/pull/4676
Кстати, классные и дружелюбные мейнтейнеры (называю их за глаза "мои итальянцы"), но уже месяца два не могу дождаться релиза - возможно готовят мажорку или просто хотят большой скоуп фичей за раз.
Так вот, наша особенность - SSR приложения требуют универсальные интерфейсы для сервера и для браузера, для этих целей у нас реализована библиотека @tinkoff/request, которая работает поверх
Если посмотреть на список плагинов @tinkoff/request - https://tramvaijs.github.io/request/docs/plugins/index - мы увидем те же кэши, дедупликацию, circuit breaker (очень кстати эффективный механизм для кейсов когда в обычном виде кэширование не подходит, но можно делать фаллбэк кэши на случай сбоев), в общем все что нужно для хорошего http клиента и не завязано на конкретное окружение.
Специфичные под серверное окружение вещи (dns кэши и прочее) мы настраиваем уже на уровне отдельных Tramvai модулей.
Теперь же получается, что мы дублируем функционал Undici, а было бы очень круто переиспользовать все его возможности - но упираемся в то, что в браузере у нас обычный
Кажется, было бы очень полезно если бы браузерный
С другой стороны, многие вещи уже идут в браузере из коробки - кэширование с учетом Cache-Control, E-tag и прочих заголовков, переиспользование TCP сокета открытого под конкретных хост, а все отправленные запросы доступны через
И возможно опциональные изменения нужны именно в браузерные механизмы работы сетевых запросов, или в саму спеку HTTP протокола, где ту же дедупликацию мы могли бы настроить через новые HTTP-заголовки?
По сути, сейчас Undici закрывает практически все кейсы, которые мы хотим видеть для эффективных серверных запросов:
- кэширование запросов
- дедупликация запросов
- ретрай запросов
- проксирование и поддержка переменных окружения http_proxy/no_proxy
- переиспользование tcp сокетов (из коробки, а с http.request для этого нужно прокидывать явно Agent с keepAlive: true)
- dns кэширование
- circuit breaker
- мониторинг/логирование через diagnostics_channel
Мы как раз активно мигрируем на
undici.fetch в Tramvai на замену node-fetch, и это уже вылилось в несколько небольших доработок в undici:- мониторинг кэша - https://github.com/nodejs/undici/pull/4589
- мониторинг прокси - https://github.com/nodejs/undici/pull/4659
- env proxy ближе к стандарту - https://github.com/nodejs/undici/pull/4676
Кстати, классные и дружелюбные мейнтейнеры (называю их за глаза "мои итальянцы"), но уже месяца два не могу дождаться релиза - возможно готовят мажорку или просто хотят большой скоуп фичей за раз.
Так вот, наша особенность - SSR приложения требуют универсальные интерфейсы для сервера и для браузера, для этих целей у нас реализована библиотека @tinkoff/request, которая работает поверх
fetch в браузере и теперь уже поверх undici.fetch в ноде.Если посмотреть на список плагинов @tinkoff/request - https://tramvaijs.github.io/request/docs/plugins/index - мы увидем те же кэши, дедупликацию, circuit breaker (очень кстати эффективный механизм для кейсов когда в обычном виде кэширование не подходит, но можно делать фаллбэк кэши на случай сбоев), в общем все что нужно для хорошего http клиента и не завязано на конкретное окружение.
Специфичные под серверное окружение вещи (dns кэши и прочее) мы настраиваем уже на уровне отдельных Tramvai модулей.
Теперь же получается, что мы дублируем функционал Undici, а было бы очень круто переиспользовать все его возможности - но упираемся в то, что в браузере у нас обычный
fetch, а у мейнтейнеров Undici в принципе планов на веб нет (и это вполне оправданно).Кажется, было бы очень полезно если бы браузерный
fetch расширяли новыми возможностями (по принципу тех же interceptors в Undici), и браузерное API поставляло бы готовые сущности для таких базовых вещей как дедупликация и ретрай запросов, мониторинг, да и наверное проксирование.С другой стороны, многие вещи уже идут в браузере из коробки - кэширование с учетом Cache-Control, E-tag и прочих заголовков, переиспользование TCP сокета открытого под конкретных хост, а все отправленные запросы доступны через
performance.getEntries('fetch').И возможно опциональные изменения нужны именно в браузерные механизмы работы сетевых запросов, или в саму спеку HTTP протокола, где ту же дедупликацию мы могли бы настроить через новые HTTP-заголовки?
GitHub
feat: add circuit breaker interceptor by mcollina · Pull Request #4700 · nodejs/undici
Summary
Adds a per-host/route circuit breaker interceptor for resilient HTTP client behavior.
Features
Three circuit states: CLOSED (normal operation), OPEN (fast-fail), HALF_OPEN (testing recover...
Adds a per-host/route circuit breaker interceptor for resilient HTTP client behavior.
Features
Three circuit states: CLOSED (normal operation), OPEN (fast-fail), HALF_OPEN (testing recover...
🔥11👍7🤔3
Встречал на практике кейс с десятками запросов на старте, где каждый fetch занимал 2-4 синхронных миллисекунды, и в сумме это казалось прям катастрофой. А оказывается это может быть лишь оверхэд на девтулзы...
👍9🤡3😁2
Forwarded from Иван Акулов про разработку
Что ещё
😑 Потратил на это выходные, поэтому сэкономлю их вам:
Оказывается, когда вы открываете девтулзы в Chrome, таймеры (и любые другие нативные функции —
Это проблема! Перформанс обычно измеряется с открытыми девтулзами. Из-за того, что таймеры в этом режиме кажутся дорогими, TanStack Query, например, имплементировал целое API, чтобы менеджить таймеры, а Сергей Гарин ушёл даже дальше и почти переписал таймер-менеджмент целиком.
Мини-тред с исследованием (где в конце приходит Пол Айриш из Google и говорит, что все мы делали всё это зря): раз, два, три
😑 Потратил на это выходные, поэтому сэкономлю их вам:
Оказывается, когда вы открываете девтулзы в Chrome, таймеры (и любые другие нативные функции —
fetch, requestAnimationFrame и т.д.) становятся в 5-100 раз медленнее. Это происходит вне зависимости от того, делаете ли вы что-то в девтулзах или нет — достаточно того, чтобы они были открыты.Это проблема! Перформанс обычно измеряется с открытыми девтулзами. Из-за того, что таймеры в этом режиме кажутся дорогими, TanStack Query, например, имплементировал целое API, чтобы менеджить таймеры, а Сергей Гарин ушёл даже дальше и почти переписал таймер-менеджмент целиком.
Мини-тред с исследованием (где в конце приходит Пол Айриш из Google и говорит, что все мы делали всё это зря): раз, два, три
👍10❤4😱2
Занимался сейчас оптимизацией времени старта @tramvai/cli, и самый популярный паттерн такой:
- снять CPU profile
- найти самые тяжелые CJS require вызовы
- если импортируемые пакеты не используются, заменить обычный import в начале файла на
Буквально несколько тяжелых импортов зря занимали 500-1000ms на старте скрипта, очень эффективная и простая оптимизация, хоть и требует ручной работы + смешивать CJS + ESM.
Есть классный пропозал с defer import - https://github.com/tc39/proposal-defer-import-eval
Но проблема та же, что вручную надо определить, что нам требуется не сразу.
Плюс запустить это можно только на собранном через бандлер коде на данный момент - https://webpack.js.org/configuration/experiments/#experimentsdeferimport
Еще одна приятная оптимизация - замена
Следующий момент вдохновлен вебпаковским thread-loader, опишу сначала сам пайплайн dev сборки (трейс на вложенном изображении):
- наша cli запускает процессы сборки серверного и клиентского кода
- также она стартует воркер для фетча и запуска собранного server.js
- соответственно этот воркер простаивает зря все время пока собирается серверный код
Добавил на старте воркера прогрев самого тяжелого модуля -
Получаю большое удовольствие от такой работы, хоть теперь и не доверяю Chrome Devtools Performance как прежде :)
- снять CPU profile
- найти самые тяжелые CJS require вызовы
- если импортируемые пакеты не используются, заменить обычный import в начале файла на
require(lib) по месту вызоваБуквально несколько тяжелых импортов зря занимали 500-1000ms на старте скрипта, очень эффективная и простая оптимизация, хоть и требует ручной работы + смешивать CJS + ESM.
Есть классный пропозал с defer import - https://github.com/tc39/proposal-defer-import-eval
Но проблема та же, что вручную надо определить, что нам требуется не сразу.
Плюс запустить это можно только на собранном через бандлер коде на данный момент - https://webpack.js.org/configuration/experiments/#experimentsdeferimport
Еще одна приятная оптимизация - замена
require('date-fns') на require('date-fns/format'), минус 350ms - кажется бесполезный налог на жирный barrel файл - точку входа date-fns.Следующий момент вдохновлен вебпаковским thread-loader, опишу сначала сам пайплайн dev сборки (трейс на вложенном изображении):
- наша cli запускает процессы сборки серверного и клиентского кода
- также она стартует воркер для фетча и запуска собранного server.js
- соответственно этот воркер простаивает зря все время пока собирается серверный код
Добавил на старте воркера прогрев самого тяжелого модуля -
require('fastify') - итого минус 200ms на старт development сервера приложения.Получаю большое удовольствие от такой работы, хоть теперь и не доверяю Chrome Devtools Performance как прежде :)
👍11🔥4
Забыл еще про один небольшой кейс в этом наборе оптимизаций.
На старте cli проверяем текущую версию
Проверка сделана через
Занимает этот вызов в итоге 300-600ms у v4 yarn, асинхронный
В качестве воркэраунда добавил сначала проверку на наличие поля
Вроде бы все низковисящие фрукты собрал.
На старте cli проверяем текущую версию
yarn, а уже для v1 и для berry у нас разные обертки для работы с зависимостями.Проверка сделана через
child_process.execSync, вызываемая команда - yarn -vЗанимает этот вызов в итоге 300-600ms у v4 yarn, асинхронный
exec ситуацию не исправил и как будто бы даже замедлил в сумме.В качестве воркэраунда добавил сначала проверку на наличие поля
packageManager в package.json приложения - должно быть в любом проекте с corepack.Вроде бы все низковисящие фрукты собрал.
🔥3👍2