性能比拼: Deno vs. Node.js vs. Bun (2025版)

本内容是对知名性能评测博主 Anton Putra Deno vs. Node.js vs. Bun: Performance Comparison 2025 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

在本视频中，我们将使用当前可用的最新版本对 Node.js、Bun 和 Deno 进行比较。我决定更新本视频，以包含 Bun 提供的原生 API，例如 Postgres、S3 等。

在第一个基础测试中，我们将测量每个应用程序的延迟（latency）、吞吐量（throughput）、可用性（availability）以及资源饱和度（saturation）。

第二个测试更具吸引力，我引入了 Postgres 数据库，并使用了 Bun 提供的最新原生 Postgres API 进行测试。

所有测试均在 AWS 上运行，并使用了与 真实生产环境 相同的基础设施，即这些应用实际上可以服务于真实用户。

---

第一个测试：静态请求处理

好了，让我们开始第一个静态测试。

在这个测试中，服务器仅在收到 GET 请求（/api/users 端点） 时返回硬编码的对象。

你可以在我的 GitHub 公开仓库 中找到该测试的源代码。

整个测试持续了大约 1.5 小时，但在编辑时，我将其压缩到几分钟。

在本测试中，我们测量了以下指标：

• P90 延迟（Latency）：GET 请求的 90% 百分位延迟。
• 吞吐量（Throughput）：每个应用每秒可处理的请求数。
• CPU 使用率（CPU Usage）：计算的是 运行每个应用程序的两个 Pod 的平均 CPU 使用率。
• 内存使用率（Memory Usage）。
• 可用性（Availability）：即错误率。
• CPU 限流（CPU Throttling）：由于应用运行在 Kubernetes 中，我们需要测量 Pod 试图使用超出其分配 CPU 资源的情况。

此外，我使用 Node.js 的标准库 创建了 Web 服务器，并对 Bun 和 Deno 也做了相同的处理，以确保所有应用在本次测试中返回完全相同的硬编码对象。

现在，让我们再运行 1 分钟，然后逐个分析测试结果。

---

吞吐量（Requests Per Second）

• Node.js：48,000 次请求/秒
• Deno：62,000 次请求/秒
• Bun：85,000 次请求/秒

💡 小提醒：

• Bun 基于 Zig 语言。
• Deno 基于 Rust。
• Node.js 基于 V8 JavaScript 引擎。

延迟（Latency）

• 延迟越低，性能越好。
• Node.js 的延迟最高，而 Bun 在本次测试中表现最佳。
• 由于我在本次测试中使用了 原生库，Deno 和 Bun 可以利用其运行时进行优化，因此它们的性能更佳。

CPU 使用率（CPU Usage）

CPU 资源的利用率符合预期，Bun 在本次测试中表现优异。

内存使用率（Memory Usage）

请注意 Bun 的内存使用情况，在本次测试中，它占用最少的内存，但这将在下一个测试中发生变化。

可用性（Availability）

所有应用程序的可用性保持在较高水平，没有出现重大错误率。

CPU 限流（CPU Throttling）

CPU 限流情况表明 Bun 在高负载下的资源管理较为高效。

---

第一个测试结论

在第一个测试中，Bun 的性能明显优于其他应用，无论是吞吐量、延迟、CPU 使用率还是资源优化，它都表现最佳。

现在，让我们看看当引入数据库时会发生什么。

---

第二个测试：PostgreSQL 数据库

在第二个测试中，客户端向每个应用程序发送 POST 请求，然后应用程序解析请求体并将数据保存到关系型数据库（PostgreSQL 17.2）。

本视频的灵感来源于 Bun 声称提供 Postgres、S3 等操作的原生 API。因此，我使用了 Bun 最新的原生 Postgres API 进行测试。

💡 但这里遇到了一个问题：

• Bun 的 Postgres 原生 API 文档并不完善，甚至官方示例代码都无法正常运行。
• 我最终是在 GitHub 讨论帖 中找到了解决方案。
• 虽然这个 Postgres 驱动仍处于早期阶段，但我仍然希望测试它的性能。

---

S3 上传测试

实际上，我还测试了 Bun 的原生 S3 驱动，用于上传图片到 S3 存储桶。

• Bun 的 S3 原生 API 明显优于 AWS SDK v3，在性能上有很大的提升。

---

数据库连接池

• Bun 的 Postgres 驱动目前无法手动调整连接池大小，并且默认硬编码为 10 个连接/实例。
• 在本次测试中，我部署了 2 个实例，因此 总共 20 个数据库连接（10 连接/实例）。
• 其他应用程序根据负载动态调整连接池大小，我为每个实例设置了 250 连接的上限，总共 500 连接。

---

测试结果

• Bun 在本次测试中的吞吐量仍然表现优异，达到了 18,000 次请求/秒。
• 由于 Bun 采用 JavaScript + Zig 封装，并且我使用了 Bun 的原生 API，它能够比其他使用第三方库的应用程序优化得更好。

POST 请求延迟（Latency）

• Bun 仍然具有最低的 POST 请求延迟。

数据库延迟（Database Latency）

• 数据库访问延迟表现良好。

内存使用情况（Memory Usage）

💡 问题来了！

• Bun 的原生 Postgres 实现存在内存泄漏（Memory Leak）。
• 在测试过程中，应用程序多次达到内存上限，导致 Kubernetes 触发 OOMKill 事件并重启实例。

---

最终结论

• Bun 提供的原生 API（如 Postgres、S3）在性能上有巨大优势，但它们目前还不适用于生产环境。
• 由于这些 API 直接集成在 Bun 运行时，它们始终会缺少一些外部数据库和对象存储提供的新特性。
• 但这也是 优化 JavaScript 运行时 的唯一方式。

💡 Deno 的问题：

• 如果 Deno 使用未针对 Rust 进行优化的第三方库，它的性能甚至比标准 Node.js 运行时还要慢。

💡 JavaScript 运行时的发展方向？

• 这些 JavaScript 运行时是否能长期维持维护这些原生 API？
• 他们是否必须开发和维护自己的原生 API 才能超越 Node.js？

---