Rust 与 Node.js：后端基准测试和延迟

该英文文本是根据法文原文自动生成的，尚未经过审查。

该页面已自动翻译。英文版具有权威性。

我们自己没有运行这个长凳：这些是第三方公开的数据，来源和日期。本文详细介绍了他们的说法、其背后的方法以及后端选择的实际变化，而不是 Aurabase 与竞争对手的比较。

Aurabase 的核心在 Rust 中运行，在 axum 和 tokio 上 — 在 monorepo 的 Cargo.toml 中进行了验证，十个服务共享相同的依赖关系。但迄今为止我们还没有公布任何我们自己的业绩数据。如果您正在寻找精确的 Aurabase 延迟，那么它还不存在：方法将出现在数字之前，而不是相反。

要点

在 Sharkbench（社区基准，Ryzen 7 7800X3D，Docker/Linux，08/24/2025）上：Actix、Hyper、Axum 和 Rocket 的运行速度均在 18,047 到 21,965 请求/秒之间，速度为 1.4-1.7 毫秒。 Node.js 端的 Fastify、Koa 和 Express 上限为 5,766 到 9,340 个请求/秒，时间为 3.4-5.5 毫秒。
运行时的权重与语言的权重一样大：相同的 Express 代码从 Node.js 上的 5,766 req/s 到 Bun 上的 18,917 req/s — 系数 ×3.3，而无需更改一行。
内存差距是最明显的：Axum 为 8.5 MB，而 Express/Node.js 为 82.5 MB — 与 Rust 垃圾收集器的缺失一致。
迄今为止，Aurabase 尚未发布任何自己的基准。 Rust/axum/tokio 核心是在代码中检查的——而不是性能。
孤立的数字不能证明什么：硬件、框架版本、有效负载大小和竞争水平对排名的影响比语言本身的影响更大。

板凳

最近的第三方测试显示了什么

Sharkbench 是一个独立的社区项目，它衡量三件事：框架处理并发 HTTP 请求、I/O 操作和 JSON 序列化的能力。该测试在 Ryzen 7 7800X3D 上的 Docker/Linux 下运行，最后一次公开更新于 2025 年 8 月 24 日（sharkbench.dev/web，于 2026 年 8 月 24 日访问）。

来源：Sharkbench，2025 年 8 月 24 日 — Docker/Linux，Ryzen 7 7800X3D。

Axum — Aurabase 用于 Rust 核心的框架，已在 Cargo.toml 中验证 — 在此工作台上每秒处理 21,030 个请求。 Express 是生产中最常用的 Node.js 框架，在同一硬件上处理 5,766 个：3.6 倍。这并不是一个孤立的案例。测试的四个 Rust 框架都落在 18,000 到 22,000 请求/秒的狭窄范围内，而测试的三个 Node.js 框架上限在 5,766 到 9,340 之间。

实际上，“req/s”衡量的是持续并发负载下的吞吐量，而不是低流量站点上孤立请求的速度。对于每隔几秒调用一次的端点，永远看不到差异。它对于热端点（实时流、具有大流量的公共 API、将数千个调用串在一起的作业）变得具有决定性作用，其中每个 CPU 核心处理的请求数量（对于相同的硬件）直接决定了基础设施费用。

延迟

延迟遵循相同的模式

该平台上的平均延迟遵循相同的层次结构：测试的 Rust 框架为 1.4 到 1.7 毫秒，而测试的 Node.js 框架为 3.4 到 5.5 毫秒。

来源：Sharkbench，2025 年 8 月 24 日 — 中等延迟，不是 p99。

这个数字是平均值，不是p99。托管运行时中的垃圾暂停主要影响调度队列——最慢的请求，而不是中值。这是本系列专门文章的主题：为什么缺少垃圾收集器会改变 p99 延迟。

为什么

为什么 Rust 没有 GC 中断需要付出代价

Rust 按所有权管理内存，在编译时检查 - 没有垃圾收集器在后台运行并中断执行。官方 Rust 书籍总结如下： “所有权的任何功能都不会减慢程序运行时的速度” (Rust 编程语言，doc.rust-lang.org，2026 年 8 月 24 日访问)。一旦拥有它的变量超出范围，内存就会被释放——这是编译时的已知时间，而不是运行时不可预测的暂停。

ownership.rsrust

fn main() {
    let data = String::from("réponse API"); // `data` 拥有该字符串
    process(data); // 占有离开这里
    // “data”在这里不再有效——没有悬空指针，没有双重释放
} // `data` 在这里确定性地发布

fn process(s: String) {
    println!("{s}");
} // `s` 超出了这里的范围：立即释放，没有垃圾收集过程

相反，Node.js 在单个 JavaScript 线程上运行，并通过多阶段事件循环（计时器、延迟回调、轮询、检查...）将 I/O 操作委托给内核，但该线程上的任何同步计算（包括来自 V8 引擎的垃圾收集传递）都会在运行时阻止执行（官方 Node.js 文档，nodejs.org，8 月 24 日访问， 2026）。这是内存模型的差异，而不是实现细节。

细微差别

真正的惊喜：运行时与语言一样重要

来自同一个工作台的最违反直觉的结果与 Rust 无关：它与 Node.js 本身有关。 Express — 一个相同的代码，一个相同的 API — 从 Node.js 上的 5,766 个请求/秒增加到 Bun 上的 18,917 个请求/秒，系数为 ×3.3，而无需更改一行应用程序代码（Sharkbench，2025 年 8 月 24 日）。

来源：Sharkbench，2025 年 8 月 24 日 — 相同的 Express 代码，三个 JavaScript 运行时。

在 Deno 上，相同的 Express 代码上限为 6,088 req/s — 接近 Node.js，远离 Bun。 JavaScript 语言在这三种情况下都是相同的；改变游戏规则的是运行时——它的 JS 引擎、它的事件循环实现、它的垃圾收集。在不指定运行时、版本和框架的情况下比较“Rust”和“Node.js”就像比较配置，而不是语言。

并参与这一切？

在同一个测试平台上，Go Gin 框架的峰值速度为 3,546 req/s，而 FastHTTP（仍在 Go 中）则攀升至 5,567 req/s，延迟仅为 0.7 毫秒（Sharkbench，2025 年 8 月 24 日）。单一语言有两种截然不同的结果：一个孤立的人物永远无法概括整个生态系统。

方法论

为什么单一基准数字永远不够

TechEmpower 框架基准在更大范围内阐述了相同的想法。其开源存储库于 2026 年 3 月 24 日更新，最新一轮（第 23 轮）是 2026 年 3 月 16 日发布的帖子的主题（TechEmpower，于 2026 年 8 月 24 日访问）。该项目在数百个实现上运行多种类型的测试，正是因为单个测试从不代表一个框架，更不用说一种语言了。

数据库市场的参与者Convex在这个问题上表达了最明确的立场：拒绝参与竞争数据库之间的营销“条形图战争”，被认为具有误导性。 “这是缩放剧院，而不是缩放”，团队写道（Convex，2026 年 8 月 24 日访问）。我们分享这样的解读：没有公布的方法论的赤裸裸的数字无法证明任何事情——无论是对竞争对手还是对我们来说。

具体来说，它的变化是：硬件（CPU、RAM）、框架和运行时的确切版本、JSON 有效负载的大小、竞争水平和测试持续时间都会影响排名——有时比语言本身的选择还要大。不发布这些参数的工作台不会重现，因此不会验证自身 - 请参阅我们的完整且可重现的方法来对后端进行基准测试。

光环基地

还有 Aurabase 在这一切中吗？

Aurabase 的核心后端是用 Rust 编写的，在 axum 和 tokio 上 — 在 monorepo 的 Cargo.toml 中检查：十个服务（aura-gateway、 aura-auth、 aura-db…）共享相同的工作区依赖项 axum (0.8) 和相同的运行时 tokio，在 2021 版本中。除了 axum 之外，路由数据平面和管理平面流量的网关还依赖于 hyper — 完整的详细信息请参见我们关于网关的数据平面/管理平面架构的文章。支持这十项服务的 Cargo 工作区的结构记录在我们关于 Cargo 工作区的文章中。

我们还没有发布带有记录方法和硬件的 Aurabase 吞吐量或延迟数据。这是经过深思熟虑的：我们更喜欢在图表之前发布方法，而不是相反——这是本系列未来文章的主题。

有关完整的架构比较（Aurabase 的统一 Rust 核心与直接竞争对手记录的异构堆栈 Elixir/Go/TypeScript/Node），请参阅我们的详细比较 Aurabase 与 Supabase。如果您已经在迁移项目，Supabase 到 Aurabase 迁移指南涵盖架构、RLS 策略和 SDK。

数据

附录：完整数据表

本文引用的所有行均由 Sharkbench 于 2025 年 8 月 24 日发布（Docker/Linux、Ryzen 7 7800X3D）。

框架	运行时	请求/秒	延迟	内存
阿克泰克斯	铁锈	21 965	1.4毫秒	16.6MB
超级	铁锈	21 781	1.5毫秒	8.6MB
阿克苏姆	铁锈	21 030	1.6毫秒	8.5MB
火箭	铁锈	18 047	1.7毫秒	6.4MB
快速化	Node.js	9 340	3.4毫秒	57.0 MB
相思木	Node.js	8 828	3.6毫秒	53.3MB
快递	Node.js	5 766	5.5毫秒	82.5MB
快递	包子	18 917	1.3毫秒	53.3MB
快递	德诺	6 088	5.0毫秒	130.7 MB
杜松子酒	去	3 546	1.0毫秒	16.7MB
快速HTTP	去	5 567	0.7毫秒	13.4MB

引用此数据：Sharkbench，“Web 框架基准”，sharkbench.dev/web，最后更新于 2025 年 8 月 24 日。

常见问题解答

常见问题

这是否意味着 Node.js 是一个糟糕的选择？+

不会。Node.js 对于许多后端来说仍然是一个可靠的选择，特别是当团队已经精通 TypeScript 并且负载不由 CPU 计算主导时。这里衡量的差距是在激烈竞争下的原始吞吐量和延迟，而不是开发生产力或软件包生态系统。在 Bun 上，与 Rust 的差距显着缩小（Express 为 18,917 req/s，Axum 为 21,030）：运行时的选择与语言的选择一样重要。

与其他 Node.js 框架相比，为什么 Express 这么慢？+

在此测试台上，Express（Node.js 上为 5,766 个请求/秒）是测试的 Node.js 框架中最慢的，落后于 Koa（8,828）和 Fastify（9,340）。 Express 诞生于 2010 年，其设计注重中间件的简单性而不是原始吞吐量。在相同的运行时，框架的选择已经使 Express 和 Fastify 之间存在 ×1.6 的差距（Sharkbench，2025 年 8 月 24 日）。

这个基准是如何实现的，我们可以重现它吗？+

本文引用的基准来自 Sharkbench，这是一个独立社区项目，该项目在 Ryzen 7 7800X3D 上测试 Docker/Linux 下的并发 HTTP 请求、I/O 和 JSON 序列化，最终公开更新于 2025 年 8 月 24 日 (sharkbench.dev/web)。这不是 Aurabase 工作台——我们自己既没有运行也没有验证它；我们引用他是因为他的方法论和材料是公开的，这与许多营销人物不同。

Aurabase 是否发布了自己的基准？+

不，到目前为止还没有。 Aurabase 的 Rust/axum/tokio 核心在 monorepo 源代码中进行了验证，但尚未测量和发布特定于 Aurabase 的吞吐量或延迟数据。本文基于第三方来源的工作台对 Rust 和 Node.js 进行了总体比较——这不是 Aurabase 与竞争对手的比较。

吞吐量和内存的差异对基础设施费用有何影响？+

在引用的基准上，Axum 消耗 8.5 MB 内存，而 Node.js 上的 Express 消耗 82.5 MB — 接近 ×10（Sharkbench，2025 年 8 月 24 日）。每个实例的内存更少，每个 CPU 核心处理的请求更多，因此在流量相同的情况下，可以用更少或更小的实例来保持相同的负载。然而，实际影响取决于您的负载配置文件（I/O 密集型或 CPU 密集型）和您的云提供商——这个数字并不是自动节省的承诺。

结论

要记住什么

在此处引用的基准上，Rust 框架都在一个狭窄的范围内运行 - 18,000 到 22,000 请求/秒，1.4-1.7 毫秒 - 远远领先于 Node.js 本身的 Node.js 框架（5,766-9,340 请求/秒，3.4-5.5 毫秒）。但运行时与语言一样改变了情况：Bun 上的 Express 几乎赶上了 Rust 上的 Axum。

如果您仅根据原始性能评估后端，请在数字之前要求方法：硬件、版本、有效负载大小、竞争水平。 Aurabase 尚未公布自己的数据；当它发生时，方法论将是第一位的。