Comparative Analysis of Parallelism Mechanisms in Node.js, Deno, and Bun

Современные веб-приложения и серверные решения на базе JavaScript/TypeScript (JT) часто вынуждены обрабатывать большие объемы данных при высокой пропускной способности и низких задержках. Традиционная модель исполнения (single-threaded event loop) упрощает разработку, но накладывает ограничения на параллельные вычислительные задачи

Важным направлением остаётся исследование параллелизма в контексте взаимодействия JavaScript с другими языками, например, при использовании Graal.js и межъязыковых вызовов

На сегодняшний день особый интерес вызывают три платформы:

• Node.js — наиболее зрелая, с обширной экосистемой npm‑пакетов, работающая на базе движка V8.

• Deno — ориентирована на безопасность, имеет встроенный TypeScript и механизм разрешений (Permissions), использует движок V8 с обвязкой на Rust

• Bun — быстро развивающаяся платформа на JavaScriptCore, заявляющая высокую скорость запуска и совместимость с основными npm‑зависимостями

Целью данного исследования является систематическое сравнение механизмов параллелизма в трёх современных JavaScript-рантаймах: Node.js, Deno и Bun (NDB). В отличие от предыдущих работ, где анализ ограничивался двумя платформами или не охватывал параллельные вычисления в условиях различной нагрузки, в данной работе впервые применяется единая методология тестирования с повторными прогонами, статистической обработкой данных и тремя типами сценариев: CPU-bound, I/O-bound и смешанным (CIS). Вклад исследования заключается в количественной оценке ключевых показателей (latency, throughput, потребление памяти) в идентичных условиях, а также в формулировке практических рекомендаций по выбору рантайма и механизма параллелизма для высоконагруженных JavaScript-приложений.

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

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

Ряд работ исследует отдельные аспекты параллелизма. В

Также следует отметить инженерные публикации, такие как

Анализ литературы указывает на существование научного и практического пробела: отсутствует комплексное сопоставление трех современных JavaScript-рантаймов NDB в контексте различных типов нагрузки (CIS) с едиными сценариями тестирования и статистической обработкой результатов. Настоящее исследование восполняет этот пробел, предлагая воспроизводимую методологию и охватывая ключевые метрики в условиях реального параллелизма.

В современных JT‑рантаймах, включая NDB, параллелизация обычно достигается одним из двух базовых механизмов: запуском потоков (WW) или процессов (CP). Ниже кратко рассмотрены особенности каждого подхода и отмечены ключевые различия в способах их реализации в трёх упомянутых платформах.

Рабочие потоки (WW)

Механизм потоков в Node.js позволяет выполнять JavaScript‑код параллельно в пределах одного процесса, что дает возможность реализовать многопоточность без запуска дополнительных процессов. В Deno и Bun аналогичный подход реализован через Web Worker API, а в случае Bun — при наличии соответствующей поддержки — может также использоваться модуль node:worker_threads

Дочерние процессы (CP)

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

Как видно из таблицы 1, каждая платформа имеет свою специфику в части параллельного исполнения. Node.js выделяется зрелой экосистемой и широким выбором библиотек для работы с процессами и потоками, Deno привлекает встроенным TypeScript и безопасностью, а Bun — скоростью старта и активным развитием поддержки npm‑зависимостей. В последующих разделах мы подробно сравним эффективность этих механизмов при различных сценариях CIS-нагрузки и оценим, насколько они удобны для реальных проектов.

В работе исследовались CIS сценарии нагруженности, характерных для серверных JT-приложений:

1. CPU-нагрузка моделирует задачи с высокой вычислительной сложностью, например, обработку математических вычислений в цикле. Для этого была разработана функция heavyCalc, выполняющая 10 миллионов итераций с накоплением суммы, включающей такие операции, как

(1)

2. Нагрузка, ориентированная на ввод-вывод, реализуется через массовую параллельную отправку HTTP-запросов к локально развернутым сервисам, разработанным на NDB. Для генерации сетевого трафика используется инструмент wrk

3. Смешанный сценарий одновременно запускаются «тяжелые» вычислительные задачи (heavyCalc) и обрабатывается входящий HTTP‑трафик. Это позволяет оценить, как параллелизация влияет на распределение ресурсов CPU при одновременных I/O‑запросах.

Все эксперименты проводились на следующей конфигурации:

• Операционная система: Windows 10 ×64;

• Процессор: Intel Core i7‑10750H @2.60 GHz (6 ядер / 12 потоков);

• ОЗУ: ~24 GB;

• Диск: SSD (512 GB);

• Версии платформ: Node.js v22.12.0, Deno v2.1.4, Bun v1.1.42.

Для генерации и анализа данных использовались:

• wrk (HTTP‑бенчмарк);

• Встроенные профилировщики (Node.js Inspector, Deno Profiler, Bun Profiler);

• Скрипты на Python для сбора и агрегации статистики.

Для моделирования сценария CPU-bound создана функция heavyCalc, выполняющая 10 000 000 итераций (в смешанном сценарии значение увеличивается до 100 000 000). Код на JavaScript:

1const ITERATIONS = 10_000_000;
2function heavyCalc() {
3  let sum = 0;
4  for (let i = 0; i < ITERATIONS; i++) {
5    const x = Math.sqrt(i) * Math.sin(i);
6    const y = Math.log(i + 1) * Math.cos(i / 2);
7    sum += x * y;
8  }
9  return sum;
10}
11module.exports = { heavyCalc };

Для каждого типа CIS-нагрузки выполнялось n=5 прогонов. Собирались следующие метрики:

• Время выполнения (миллисекунды);

• Пропускная способность (Throughput), выраженная в операциях или HTTP‑запросах в секунду;

• Потребление памяти (RSS), по данным профилировщиков (распределённая или итоговая резидентная память).

Затем для каждого эксперимента вычислялись:

• Средние значения ;

• Стандартные отклонения ;

• 95%-доверительные интервалы CI95%.

Использовались классические формулы выборочной статистики

(2)

Стандартное отклонение s рассчитывалось по формуле:

(3)

95% — доверительный интервал CI95%, вычисляемый по формуле:

(4)

где z0,975 — квантиль стандартного нормального распределения, для больших выборок:

(5)

При n = 5 разница между z-критерием и точным распределением Стьюдента t считается несущественной.

Пропускная способность рассчитывалась как:

(6)

где  — среднее время одного вычислительного запроса (переведенное в секунды). В случае I/O-нагрузки, измеренной с помощью утилиты wrk, значение Throughput (Requests/sec) считывалось из отчёта, после чего по результатам пяти запусков также рассчитывались x̄, s и CI95% по тем же формулам.

Для проверки статистической значимости (p<0,95) в большинстве случаев применялся t-критерий Стьюдента, сравнивающий средние значения между двумя выборками (например, Node.js против Deno или Deno против Bun). Теоретически для сравнения трех групп можно использовать однофакторный анализ дисперсии (ANOVA)

Последовательность экспериментов выглядела следующим образом:

1. CPU-bound:

– Запуск платформы NDB с соответствующим механизмом параллелизма (WW ИЛИ CP).

– Выполнение 4-кратного вызова heavyCalc, замер общего времени, деление результата на 4, повтор прогонов (5 раз).

– Фиксация итоговых метрик (, Throughput, RSS).

2. I/O-bound:

– Запуск локального HTTP‑сервиса на NDB.

– Генерация нагрузки утилитой wrk (5 итераций, каждая длится 10–30 с, в зависимости от настроек).

– Сбор показателей: Requests/sec, Latency (ms), Max latency (ms), а также RSS из профилировщиков рантайма.

3. Смешанный:

– Одновременный запуск heavyCalc и приём HTTP‑запросов от wrk.

– 5 повторов с замером времени завершения CPU‑задачи и throughput/latency по отчётам wrk.

По окончании каждого сценария данные сводились в таблицы. Для каждого рантайма NDB и для каждого сценария CIS вычислялись x̄, s и CI95%. Если разница между двумя рантаймами по целевым метрикам (время, Throughput) оказывалась меньше суммарного доверительного интервала, это расценивалось как статистически не значимое расхождение.

Несмотря на тщательную подготовку и применение единого подхода к тестированию, данное исследование имеет ряд ограничений. Во-первых, использовались лишь три типовых сценария нагрузки — CIS. Однако в реальных приложениях характер нагрузки может быть более разнообразным и сложным. Во-вторых, все эксперименты проводились в локальной среде на одной аппаратно-программной конфигурации (Windows 10, процессор Intel Core i7‑10750H и т. д.), что может ограничивать обобщаемость результатов. В других операционных системах (например, Linux или macOS), а также в условиях распределённой инфраструктуры поведение рантаймов может отличаться. В-третьих, важным фактором является различная степень зрелости исследуемых платформ: Node.js существует дольше и имеет устоявшуюся экосистему, тогда как Deno и Bun являются относительно новыми решениями, API и модули которых продолжают активно развиваться. Возможные недоработки или изменения в этих средах могут оказывать влияние на измеренные показатели производительности.

Ниже представлены результаты CIS сценариев. Для каждого из них рассчитаны среднее время выполнения, пропускная способность, латентность, потребление памяти, а также 95 % доверительные интервалы. Они позволяют сравнить эффективность параллельных механизмов в разных рантаймах и оценить статистическую значимость различий. Подробности методики приведены в разделе «Методология исследования».

Таблица 2 демонстрирует данные для CPU‑bound сценария, где каждая «задача» вызывает heavyCalc (10 млн итераций) 4 раза подряд.

Примечание: число в скобках указывает количество параллельно запущенных воркеров или процессов (в данной конфигурации — 4).

Краткий анализ таблицы 2:

• Bun демонстрирует наиболее низкое среднее время выполнения (~100–105 мс на вызов) как в режиме WW, так и CP (9,5–9,8 req/s).

• Deno с WW даёт ~125 мс, что соответствует 8 req/s, а с CP — ~261 мс (3,8 req/s). Оба показателя лучше, чем у Node.js.

• Node.js при параллельном исполнении (4 потока или 4 процесса) стабильно держится в районе 2 req/s (~493–496 мс на вызов). В последовательном режиме время возрастает до ~1,6 с (0,63 req/s).

• Во всех средах параллельная модель (потоки или процессы) значительно ускоряет вычисление по сравнению с последовательной, поскольку задействуются несколько ядер CPU.

• При сравнении WW и CP в одной среде (например, Node.js, Bun) существенной разницы не замечается (разница в пределах CI). Однако между разными платформами NDB различия могут быть статистически значимыми (p < 0,05), что объясняется разной реализацией JS‑движков (JavaScriptCore vs V8) и внутренних оптимизаций.

• Последовательный режим в Deno также показал лучшие результаты по сравнению с Node.js — ~355 мс против ~1596 мс.

Во втором тесте проводилась имитация нагрузки большим количеством коротких HTTP‑запросов к каждому рантайму NDB. Таблица 3 показывает усредненную задержку и итоговый Throughput.

Средняя латентность рассчитана по метрике Latency Avg из отчётов wrk. Показатели Throughput усреднены по пяти прогонам (Requests/sec), возможны округления в пределах нескольких сотен req/s.

Краткий анализ таблицы 3:

• Deno (в режиме 4 потоков или процессов) демонстрирует почти идентичные результаты во всех режимах: латентность около 4 мс при throughput на уровне 30–31 тыс. req/s. Это может свидетельствовать о высокой эффективности реализации HTTP-сервера в std/http и низких накладных расходах при параллельном исполнении.

• Bun в режиме CP достигает ~27,5 тыс. req/s при латентности ~4,7 мс. В последовательном режиме показатели составляют ~23,3 тыс. req/s и ~4,4 мс соответственно. Различия между WW и CP находятся в пределах доверительного интервала.

• Node.js при использовании CP выходит на ~28 тыс. req/s с латентностью ~8 мс, что существенно превосходит результат в последовательном режиме (~18 тыс. req/s и ~42 мс).

• В целом, наилучший «сырой» throughput демонстрирует Deno (30–31 тыс. req/s), за ним следует Bun (22,8–27,5 тыс.), а затем Node.js (от 18 тыс. до 28 тыс. req/s в зависимости от механизма). При этом Deno и Bun удерживают среднюю латентность в пределах 4–5 мс, тогда как у Node.js в однопоточном режиме она может достигать 40 мс.

Сценарий комбинированной нагрузки объединяет выполнение вычислительной задачи с одновременной обработкой входящих HTTP-запросов. Таблица 4 содержит усредненные результаты по ключевым метрикам (среднее время завершения heavyCalc, latency, throughput) на основе пяти прогонов.

Краткий анализ таблицы 4:

• Для Node.js heavyCalc занимает 24–25 с, что заметно дольше, чем в Deno или Bun, однако параллельные механизмы позволяют ему сохранять throughput на уровне ~21–22 тыс. req/s при латенции ~4–5 мс. CPU‑процессы/потоки лишь частично разгружают главный поток.

• Deno в последовательном и worker‑режимах выполняет CPU‑задачу за ~3,5–3,8 с с высоким RPS (29–30  тыс.). При CP нагрузка растягивается до ~5,6 с, а латенция возрастает (~12 мс), но throughput всё равно ~26–27  тыс. req/s.

• Bun укладывается в 3–3,6 с на CPU‑задаче и обрабатывает ~23–25 тыс. req/s при ~4 мс задержке. Потребление памяти (25–29 MB) выше, чем у Deno (~9–10 MB), что связано с движком JavaScriptCore и различиями в GC.

• Для Deno CP заметна нестабильность latency (от 5 мс до 17–18 мс в отдельных прогонах), указывающая на дополнительные издержки при межпроцессном взаимодействии. В реальной практике подобные эффекты могут минимизироваться настройкой пулов процессов или распределением приоритетов.

• Во всех трёх платформах наиболее узким местом становится большая CPU‑задача. Сетевой ввод-вывод при этом способен обрабатывать десятки тысяч запросов/с.

Сравнительный анализ показал, что в сценариях CPU-bound платформы Bun и Deno значительно опережают Node.js по времени выполнения. В параллельных режимах вычислительные задачи завершаются за 100–300мс, тогда как в Node.js — за 400–500мс. Это преимущество объясняется более быстрой компиляцией и оптимизациями, реализованными в движке JavaScriptCore (в случае Bun), а также в Deno, где используется V8 без устаревших компонентов и с меньшим числом промежуточных абстракций.

При I/O-нагрузке Deno демонстрирует устойчивые показатели во всех режимах исполнения — последовательном, многопоточном и многопроцессном. Это может свидетельствовать о продуманной реализации обработки запросов в стандартной библиотеке. Bun показывает сопоставимую латентность, но немного уступает по количеству запросов в секунду. В то же время Node.js значительно выигрывает при использовании режима CP по сравнению с однопоточным исполнением, обеспечивая ощутимый прирост производительности.

В смешанном сценарии, объединяющем вычислительную и сетевую нагрузку, Deno и Bun существенно опережают Node.js по времени выполнения CPU-задачи: около 3–5 секунд против 24–25 секунд. Несмотря на это, все три платформы сохраняют высокий уровень пропускной способности при обработке HTTP-запросов — от 20 до 30 тысяч в секунду. Это говорит о том, что даже в условиях высокой загрузки рантаймы эффективно масштабируют сетевой ввод-вывод в фоне. В целом, Deno и Bun демонстрируют лучшую приспособленность к интенсивным CPU-нагрузкам, в то время как все три среды способны обрабатывать высокие I/O-потоки, причём Deno, как правило, обеспечивает минимальную задержку.

Дополнительно стоит отметить внедрение новых возможностей ECMAScript, способных повлиять на развитие параллельного исполнения. Все три платформы поддерживают низкоуровневые примитивы, такие как Atomics и SharedArrayBuffer, позволяющие организовать совместный доступ к памяти между потоками. Хотя они уже реализованы в базовом виде, их использование требует осторожного подхода к синхронизации и разделению ответственности между потоками. Важным шагом в развитии станет принятие предложений, находящихся в стадии стандартизации (TC39), таких как Async Context, который позволит лучше отслеживать состояние между асинхронными вызовами, а также Scheduler API, предоставляющий возможность управления приоритетами задач. Интеграция этих функций в движки V8, JavaScriptCore и другие рантаймы повысит гибкость и эффективность обработки многозадачных сценариев в JT.

Наконец, при выборе платформы следует учитывать не только производительность, но и зрелость экосистемы. Node.js на сегодняшний день обладает самой широкой поддержкой со стороны сообщества и стабилизированными API для работы с процессами, потоками и кластеризацией. Большинство популярных библиотек (например, Express, Koa, Fastify) легко интегрируются в проекты. Deno, в свою очередь, предлагает современную архитектуру с использованием ES-модулей, URL-импортов, встроенного TypeScript и системы разрешений, повышающей безопасность. Однако миграция с Node.js может быть затруднена, поскольку далеко не все npm-библиотеки полностью совместимы. Платформа Bun стремится к максимальной совместимости с Node.js и npm, поддерживает формат package.json, но использование некоторых низкоуровневых модулей, особенно C++-расширений, может вызывать проблемы. Тем не менее Bun активно развивается и уже сегодня демонстрирует высокую скорость запуска, быструю установку пакетов и общее внимание к производительности.

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

Полученные результаты показывают, что Deno и Bun в целом превосходят Node.js по производительности в задачах с высокой вычислительной нагрузкой и демонстрируют сопоставимые показатели при I/O-нагрузках. Node.js, в свою очередь, остаётся сильным за счет зрелой экосистемы, простоты интеграции и эффективного использования Child Processes при разделении сервисов. Bun подтверждает высокую скорость обработки коротких запросов, тогда как Deno предлагает надёжный HTTP-стек и встроенную поддержку TypeScript. Во всех трёх средах грамотно организованное использование потоков и процессов позволяет существенно повысить эффективность. Выбор платформы и механизма параллелизма должен основываться на характере нагрузки, требованиях к совместимости и масштабируемости. Дальнейшие исследования с участием баз данных, распределенных систем и кластеров помогут глубже оценить потенциал современных JS/TS-рантаймов. Исходный код, использованный в эксперименте, доступен в открытом репозитории