性能比拼: Pingora vs Nginx (My NEW Favorite Proxy)

本内容是对知名性能评测博主 Anton Putra Pingora vs Nginx Performance Benchmark: My NEW Favorite Proxy! 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

介绍

在本视频中，我们将对比 Nginx 和 Pingora（一个用于构建网络服务的 Rust 框架）。我们将通过以下指标进行测试：

1. 延迟：使用 P99 分位数来测量延迟，我认为这是衡量任何代理性能最重要的指标之一。
2. 吞吐量：统计每个代理每秒可以处理的请求数。
3. 可用性：测量每个代理的错误率。
4. 饱和度：通过测量 CPU 使用率、内存使用率，以及这些代理背后的应用程序的 CPU 使用率，来看服务的利用程度。

所有测试均在 AWS 上运行。在本次测试中，我使用了以下配置：

• 代理服务器使用 大规格 EC2 实例，每个实例有 2 个 CPU 和 8 GB 内存。
• 代理背后的应用程序使用 中规格实例。
• EKS 集群 用于部署监控组件以及生成负载的客户端。

测试中，Nginx 使用的是 1.27.2 版本，Pingora 使用的是 0.4.0 版本。

---

Nginx 和 Pingora 的配置

在其他人的帮助下，我优化了 Nginx 的主要配置，所有的源代码都可以在我的 GitHub 公共仓库 中找到。以下是具体配置：

1. Nginx 配置

• 配置 Nginx 根据 CPU 核心数自动设置工作进程数量。由于 EC2 实例有 2 个 CPU，所以 Nginx 创建了 两个独立的工作进程（workers）。
• 每个工作进程设置了 4 个线程，基于之前的测试结果。

• 配置了 upstream block 来连接 4 个后端应用程序，使用默认的 轮询算法（round-robin）。
• 启用了 keep-alive 功能，并设置了 proxy_connection 头。
• 启用了 HTTP/2 协议，并提供了自签名证书。

• 出于公平对比，由于 Pingora 默认没有访问日志，我在 Nginx 中也禁用了访问日志。
• 添加了一个 X-Forwarded-For 头，将真实的客户端 IP 地址转发到后端应用程序。

提示：像 Caddy 和 Traefik 这样的高级代理默认就配置了这些功能，但对于 Nginx 和 Pingora，你需要具备一定的知识和经验才能使其高效运行。

2. Pingora 配置
   • Rust 编程：Pingora 是一个用 Rust 编写的库，因此需要一些 Rust 编程知识。Rust 并不是很容易学习的语言，但它可以用来构建非常高效的应用程序。

• 创建负载均衡器：你可以像配置 Nginx 一样使用静态文件配置 Pingora 的代理。
• 健康检查：实现了每个后端服务的 主动健康检查。Nginx 的开源版本只支持 被动健康检查，即 Nginx 只有在路由请求失败后才会移除某个后端应用程序，而付费版本 Nginx Plus 则支持主动健康检查，但需要额外付费。
• 提供自签名证书，并将连接升级到 HTTP/2。
• 使用内置功能为每个请求添加 X-Forwarded-For 等头信息，同时使用默认的轮询算法。Pingora 还允许你根据需求创建自己的负载均衡算法。

• 配置文件模式：你也可以通过配置文件配置 Pingora，但需要以守护进程模式运行以应用这些设置。

为了公平对比，由于 Nginx 使用了 2 个工作进程，每个进程有 4 个线程，所以我为 Pingora 配置了 8 个线程。虽然测试了其他配置，但最终决定使用 8 线程。需要注意的是，Nginx 的线程并不处理所有工作，因此不能直接与 Pingora 的线程作比较。

---

性能基准测试

接下来运行测试。整个测试耗时约 1.5 小时，但我将结果压缩为几分钟展示。在本次测试中，我将图表的时间范围设置为 5 分钟。如果你觉得我应该恢复之前的 15 分钟间隔，请告诉我。

1. 每秒请求数（Requests per Second）

   • 左侧图表显示每个代理从客户端接收的每秒请求数。我们逐渐增加负载，直到两个代理都失败。

2. 延迟（Latency）

   • 从延迟图表中可以看到，在整个测试过程中，Pingora 的延迟始终低于 Nginx 的。在测试初期，延迟非常低时，这可能看起来不重要，但如果你有多个微服务链，每个微服务都由代理（如 Nginx 或 Pingora）处理请求，那么延迟会随着负载的增加迅速累积，尤其是在有 5 个或 10 个微服务的长链时。

3. CPU 使用率（CPU Usage）

   • 起初，Pingora 的 CPU 使用率高于 Nginx，但随着测试的进行，情况发生了变化。

4. 内存使用率（Memory Usage）

   • 在中等负载下，两者的内存使用率非常相似。但需要注意的是，许多工具在高负载下表现会有所不同，并可能因不同原因失败。

5. 保持连接（Keep-Alive）

   • 如果你使用 Nginx 作为反向代理，请确保启用了上游服务的 keep-alive 功能，否则延迟和 CPU 使用率会更高。你可以查看未启用 keep-alive 的基准测试结果，并与本次测试进行对比。我在描述中也附上了解决方法的 PR。Pingora 自动启用了 keep-alive，但你可以调整连接池大小，我对两个代理设置了相同的池大小。

6. 可用性（Availability）

   • 通常情况下，两个代理在负载增加到 20,000 请求每秒之前都能保持 100% 可用性，并且延迟低于 1 毫秒。这对于任何代理来说都是非常优秀的性能。

---

测试结果

接下来，我们查看整个测试的图表结果：

1. 每秒请求数（Requests per Second）

• Nginx 达到了 41,000 请求/秒，而 Pingora 达到了 48,000 请求/秒。

2. 延迟（Latency）

• Pingora 在整个测试过程中始终保持最低延迟，即使在测试结束时也非常稳定。

刚开始时的延迟相差并不大

3. 可用性（Availability）

• Nginx 的可用性出现了一些下降，但仍保持在 99.99%，这完全可以接受。

4. CPU 使用率（CPU Usage）

• 虽然 Pingora 在测试初期的 CPU 使用率明显更高，但最终 CPU 使用率趋于一致，Pingora 实现了更高的吞吐量。

5. 内存使用率（Memory Usage）

• 在 CPU 密集型应用程序和性能测试中，内存使用通常不是关键因素。

6. 后端应用程序的 CPU 使用率

• Nginx 的后端应用程序 CPU 使用率略高，但仅在测试结束时 Nginx 开始失败时才出现这种情况。整个测试中，两者的 CPU 使用率几乎相同。

7. 网络使用情况

---

总结

如果你有编程经验并追求高性能，Pingora 是一个不错的选择。不过请记住，它是一个需要用 Rust 构建代理的库，如果你觉得 Nginx 已经很复杂，那么使用 Rust 构建一个类似 Nginx 的代理可能会更具挑战性。尽管如此，我会考虑在未来的生产项目中使用 Pingora。

我还有其他基准测试，你可能会感兴趣。感谢观看，我们下次见！