Миф против реальности: реальная производительность выполнения Node.js, Deno и Bun
22 июля 2025 г.Введение
В мире среда JavaScript на стороне сервера Node.js остается де-факто стандартом в течение более десяти лет, широко используемых в крупномасштабных производственных системах в различных доменах. Тем не менее, в последние годы появились альтернативные времена забега, такие как Deno и Bun, появились с их заявленными преимуществами производительности и современной архитектурой.
Deno, представленный оригинальным создателем Node.js, был разработан для устранения ограничений node.js путем предложения Enhanced Security, современной системы модулей и поддержки TypeScript из коробки. Bun, с другой стороны, является более новым участником, сосредоточенным в основном на высокоэффективном выполнении, быстроте запуска и интегрированном инструментальном положении. И Deno, и Bun представляют тесты, которые предполагают существенные улучшения производительности по сравнению с Node.js (иногда от 4 раза до 5x).
Тем не менее, эти критерии часто основаны на высокопрофессиональных примерах, таких как HTTP-серверы «Hello World», которые не отражают сложности реальных приложений.
Чтобы понять и подтвердить претензии, в этой статье представлен сравнительный анализ эффективности Node.js, DENO и BUN, используя реалистичное примерное исследование: служба сокращения URL. В отличие от минимальных контрольных показателей, это приложение имитирует рабочую нагрузку производственного класса, включающая маршрутизацию, проверку ввода, доступ к базе данных и асинхронные операции.
Цель этого исследования состоит в том, чтобы оценить, может ли опубликованный разрыв в производительности между этими временами пробежки все еще можно увидеть в практических условиях, и определить, соответствуют ли претензии превосходной производительности при применении к реальным делам.
Оценивая эти время выполнения в соответствии с реальными рабочими нагрузками, эта статья направлена на проверку претензий, тем самым помогая разработчикам и архитекторам выбрать правильное время выполнения для своих предстоящих проектов.
Настройка теста
Все тесты были проведены на MacBook Pro с чипом Apple M2 с 12 ядрами процессора и 16 ГБ оперативной памяти.
Для обеспечения высококачественной генерации нагрузки широко признанныйБомбардираИнструмент был использован. Инструмент был настроен для отправки случайного и уникального URL в корпусе запроса, отформатированного как строка JSON.
Bombardier был настроен на моделирование постоянной нагрузки из 100 параллельных соединений, выполнив в общей сложности 1 млн запросов на тест.
Были использованы следующие версии программного обеспечения, все они были в курсе тестирования:
- Node.js: v24.4.1
- Дено: v2.4.2
- Булочка: v1.2.18
Для каждой среды выполнения была выбрана самая быстрая доступная веб -структура для обеспечения оптимальной производительности:
- Node.jsПриложение: построено сФормификация
- ДеноПриложение: построено сХоно
- БулочкаПриложение: построено сЭлисия
Все тесты взаимодействовали сPostgresqlБаза данных, широко принятая система с открытым исходным источником с объектно-релационной базой с более чем 35-летним развитием. PostgreSQL хорошо известен своей надежностью, обширным набором функций и сильной производительностью.
Единственная таблица с именемshortenedurlsиспользовался для всех операций базы данных. Эта таблица хранит как оригинальные, так и укороченные URL -адреса. Его структура заключается в следующем:
Перед каждым испытанием таблица усечена, так что индекс не становится негабаритным и замедляет приложение, работающее позже в цикле испытаний.
Приложения
Каждое приложение использует отдельную веб -структуру, что приводит к небольшим различиям в реализации приложения. Однако основная функциональность остается последовательной. Для сравнительного анализа было выбрано приложение для сокращения URL, так как оно представляет собой реальный вариант использования, оставаясь достаточно простым для контролируемого тестирования.
Приложение оценивает производительность в следующих операциях:
- JSON SAINGING с входящего запроса
- Проверка запроса
- Чтение базы данных через ORM
- JSON Response Construction
Реализация для каждого приложения подробно описана ниже:
Node.js
https://gist.github.com/mayankchoubey1/9d30a9dcabd6f3ec8792479d18265c52?embedable=true
Дено
https://gist.github.com/mayankchoubey1/91e56e8dfca00c0ed83ab39a460463bd?embedable=true
Булочка
https://gist.github.com/mayankchoubey1/b2e05bfbB2002222CDE222CD0847E9fed?embedable=true
Результаты
Каждый тест проводится с 1 миллионами запросов. Следующие показатели производительности записываются для каждого тестового прогона:
- Общее время для выполнения 1 миллиона запросов
- Запросы в секунду (RPS)
- 25 -й процентиль задержка
- Средняя задержка
- Средняя задержка
- 75 -й процентиль задержка
- Максимальная задержка
- Использование процессора
- Использование памяти
Важно отметить, что потребление ресурсов - специфично ЦП и использование памяти - так же важно, как и необработанная производительность. Более быстрое время выполнения, которое несет значительно более высокие затраты на ресурсы, может не обеспечить практическую ценность в реальных сценариях.
Результаты в форме батонной диаграммы представлены ниже:
Все результаты вместе в табличной форме следующие:
Заключение
Таким образом, в то время как Bun и Deno демонстрируют немного лучшую производительность, чем Node.js, разница маргинала. Node.js обеспечивает приблизительно 12 тыс. Запросов в секунду (RPS), по сравнению с 12,4 тыс. С DEDO и BUN. Это не представляет значительного прироста производительности - конечно, не часто требуется улучшение 2x или 3x.
Таким образом, любое решение мигрировать от node.js, давнего лидера в экосистеме выполнения JavaScript, вряд ли будет вызвано необработанными показателями производительности. Вместо этого такой шаг, скорее всего, будет мотивирован другими факторами, такими как поддержка нативного типового типового, встроенная модель разрешений, современная архитектура времени выполнения или функции развертывания, такие как Deno Deploy.
По сути, только производительность не оправдывает отказа от узла. Преимущества лежат в другом месте.
Оригинал