Rust против Node.js: внутренний тест и задержка

Sharkbench — это независимый проект сообщества, который измеряет три вещи: способность платформы обрабатывать одновременные HTTP-запросы, операции ввода-вывода и сериализацию JSON. Тест проводится под Docker/Linux на Ryzen 7 7800X3D, последнее общедоступное обновление выпущено 24 августа 2025 г. (Sharkbench.dev/web, по состоянию на 24 августа 2026 г.).

Источник: Sharkbench, 24 августа 2025 г. — Docker/Linux, Ryzen 7 7800X3D.

Axum — фреймворк, который Aurabase использует для своего ядра Rust, проверенный в Cargo.toml — обрабатывает на этом стенде 21 030 запросов в секунду. Express, платформа Node.js, наиболее используемая в производстве, обрабатывает 5766 на одном и том же оборудовании: коэффициент 3,6. Это не единичный случай. Все четыре протестированных фреймворка Rust попадают в узкий диапазон от 18 000 до 22 000 запросов/с, а три протестированных фреймворка Node.js — между 5 766 и 9 340.

На практике «req/s» измеряет пропускную способность при постоянной параллельной нагрузке, а не скорость изолированного запроса на сайте с низким трафиком. Для конечной точки, вызываемой раз в несколько секунд, разница никогда не заметна. Это становится решающим для горячей конечной точки — потока в реальном времени, общедоступного API с интенсивным трафиком, задания, объединяющего тысячи вызовов — где количество запросов, обработанных на одно ядро ​​ЦП, при одинаковом оборудовании напрямую определяет расходы на инфраструктуру.

Средняя задержка соответствует той же иерархии на этом стенде: от 1,4 до 1,7 мс для протестированных фреймворков Rust по сравнению с 3,4–5,5 мс для протестированных фреймворков Node.js.

Источник: Sharkbench, 24 августа 2025 г. — средняя задержка, не p99.

Этот показатель является средним, а не р99. Мусорные паузы в управляемой среде выполнения в основном влияют на очередь отправки — самые медленные запросы, а не медианные. Это тема отдельной статьи из этой серии: , почему отсутствие сборщика мусора меняет задержку p99.

Rust управляет памятью по принципу владения, что проверяется во время компиляции — сборщик мусора не работает в фоновом режиме и не прерывает выполнение. Официальная книга Rust резюмирует это следующим образом: «Ни одна из особенностей владения не замедлит работу вашей программы во время ее работы» (The Rust Programming Language, doc.rust-lang.org, по состоянию на 24 августа 2026 г.). Память освобождается, как только владеющая ею переменная выходит за пределы области действия — известное время во время компиляции, а не непредсказуемая пауза во время выполнения.

fn main() {
    let data = String::from("réponse API"); // `data` владеет строкой
    process(data); // владение уходит отсюда
    // `data` здесь больше недействителен — ни висячего указателя, ни двойного освобождения.
} // `данные` публикуются здесь детерминированно

fn process(s: String) {
    println!("{s}");
} // `s` здесь выходит за рамки: немедленный выпуск, без прохода по сборке мусора

Node.js, наоборот, работает в одном потоке JavaScript и делегирует операции ввода-вывода ядру через многофазный цикл событий (таймеры, отложенные обратные вызовы, опрос, проверка...) — но любые синхронные вычисления в этом потоке, включая этап сборки мусора из движка V8, блокируют выполнение во время его работы (официальная документация Node.js, nodejs.org, доступ к августу 24, 2026). Это разница в модели памяти, а не в деталях реализации.

Самый нелогичный результат того же стенда не касается Rust: он касается самого Node.js. Express — один и тот же код, одно и то же API — переходит с 5766 запросов/с на Node.js до 18 917 запросов/с на Bun, в ×3,3 раза, без изменения ни строчки кода приложения (Sharkbench, 24 августа 2025 г.).

Источник: Sharkbench, 24 августа 2025 г. — тот же код Express, три среды выполнения JavaScript.

В Deno тот же код Express ограничивается скоростью 6088 запросов/с — близко к Node.js, но далеко от Bun. Язык JavaScript идентичен во всех трех случаях; Именно среда выполнения — ее JS-движок, реализация цикла событий, сборка мусора — меняет игру. Сравнивать «Rust» и «Node.js» без указания среды выполнения, версии и фреймворка — это всё равно, что сравнивать конфигурации, а не языки.

TechEmpower Framework Benchmarks иллюстрирует ту же идею в более широком масштабе. Его репозиторий с открытым исходным кодом был обновлен 24 марта 2026 г., а его последний раунд (раунд 23) был предметом публикации от 16 марта 2026 г. (TechEmpower, по состоянию на 24 августа 2026 г.). В этом проекте выполняется множество типов тестов на сотнях реализаций именно потому, что один тест никогда не представляет собой структуру, не говоря уже о языке.

Компания Convex, игрок на рынке баз данных, сформулировала наиболее четкую позицию по этому вопросу: отказываясь участвовать в маркетинговой «войне гистограмм» между конкурирующими базами данных, которая считается вводящей в заблуждение. «Это масштабирование театра, а не масштабирование»,, пишет команда (Convex, по состоянию на 24 августа 2026 г.). Мы разделяем это мнение: голая цифра без опубликованной методологии ничего не доказывает — ни для конкурента, ни для нас.

Что это меняет конкретно: аппаратное обеспечение (ЦП, ОЗУ), точная версия платформы и время выполнения, размер полезной нагрузки JSON, уровень конкуренции и продолжительность теста — все это влияет на рейтинг — иногда больше, чем сам выбор языка. Стенд, который не публикует эти параметры, не воспроизводит и, следовательно, не проверяет себя — см. нашу полную и воспроизводимую методологию для сравнительного анализа серверной части.

Основной бэкэнд Aurabase написан на Rust, на axum и tokio — проверено в Cargo.toml монорепозитория: десять сервисов (aura-gateway, aura-auth, aura-db…) используют одну и ту же зависимость рабочего пространства axum (0.8) и одну и ту же среду выполнения tokio, в 2021 г. издание. Шлюз, который маршрутизирует трафик плоскости данных и плоскости управления, в дополнение к axum использует hyper — полную информацию можно найти в нашей статье об архитектуре плоскости данных/управления шлюза. Структура рабочей области Cargo, поддерживающей эти десять сервисов, описана в нашей статье о рабочей области Cargo.

Чего у нас еще нет, так это опубликованных данных о пропускной способности или задержке Aurabase с документированной методологией и аппаратным обеспечением. Это намеренно: мы предпочитаем публиковать методологию перед рисунком, а не наоборот — это тема будущей статьи этой серии.

Для полного сравнения архитектуры — унифицированного ядра Rust в Aurabase и гетерогенного стека Elixir/Go/TypeScript/Node, задокументированного у прямого конкурента — см. наше подробное сравнение Aurabase и Supabase. Если вы уже выполняете миграцию проекта, руководство по миграции Supabase на Aurabase описывает схему, политики RLS и SDK.

Все строки, приведенные в этой статье, опубликованы Sharkbench 24 августа 2025 г. (Docker/Linux, Ryzen 7 7800X3D).

Приведите эти данные: Sharkbench, «Бенчмарки веб-платформы», Sharkbench.dev/web, последнее обновление 24 августа 2025 г.

На приведенном здесь стенде все фреймворки Rust работают в узком диапазоне — от 18 000 до 22 000 запросов/с, 1,4–1,7 мс — намного опережая фреймворки Node.js на самом Node.js (5766–9340 запросов/с, 3,4–5,5 мс). Но среда выполнения меняет ситуацию не меньше, чем язык: Express на Bun почти догоняет Axum на Rust.

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