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

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

介绍

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

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

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

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

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

Nginx 和 Pingora 的配置

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

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，你需要具备一定的知识和经验才能使其高效运行。

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 分钟间隔，请告诉我。

每秒请求数（Requests per Second）
- 左侧图表显示每个代理从客户端接收的每秒请求数。我们逐渐增加负载，直到两个代理都失败。
延迟（Latency）
- 从延迟图表中可以看到，在整个测试过程中，Pingora 的延迟始终低于 Nginx 的。在测试初期，延迟非常低时，这可能看起来不重要，但如果你有多个微服务链，每个微服务都由代理（如 Nginx 或 Pingora）处理请求，那么延迟会随着负载的增加迅速累积，尤其是在有 5 个或 10 个微服务的长链时。
CPU 使用率（CPU Usage）
- 起初，Pingora 的 CPU 使用率高于 Nginx，但随着测试的进行，情况发生了变化。
内存使用率（Memory Usage）
- 在中等负载下，两者的内存使用率非常相似。但需要注意的是，许多工具在高负载下表现会有所不同，并可能因不同原因失败。
保持连接（Keep-Alive）
- 如果你使用 Nginx 作为反向代理，请确保启用了上游服务的 keep-alive 功能，否则延迟和 CPU 使用率会更高。你可以查看未启用 keep-alive 的基准测试结果，并与本次测试进行对比。我在描述中也附上了解决方法的 PR。Pingora 自动启用了 keep-alive，但你可以调整连接池大小，我对两个代理设置了相同的池大小。
可用性（Availability）
- 通常情况下，两个代理在负载增加到 20,000 请求每秒之前都能保持 100% 可用性，并且延迟低于 1 毫秒。这对于任何代理来说都是非常优秀的性能。