本内容是对知名性能评测博主 Anton Putra 2周前 Nginx vs. HAProxy vs. Traefik: Performance[1] 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

介绍

在本视频中，我们将比较 Nginx、HAProxy 和 Traefik，使用的是截至目前可用的最新版本。

我们将从客户端测量 p90 百分位数的延迟，并评估每个代理服务器能够处理的 每秒请求数、代理服务器的 CPU 使用率、代理服务器后端应用的 CPU 使用率，以及它们的 可用性或错误率。

测试设计

我使用 AWS 来运行所有测试，并在代理服务器和每个应用程序上都使用 m7a.large EC2 实例。
每个虚拟机（VM）都配备了 2 个 CPU 和 8GB 内存。此外，我使用了 EKS 集群 来运行我的监控组件，例如 Prometheus、Grafana 等。
在该集群中，我部署了一个 Kubernetes 任务（Job）来生成负载的客户端。

每个代理服务器都使用了 TLS 证书 来支持 HTTPS，并且：

• 客户端与代理服务器 之间使用 HTTP/2 协议
• 代理服务器与后端应用 之间使用 HTTP/1.1 协议

此外，每个虚拟机都运行了 Node Exporter，并且我在客户端中添加了 Prometheus 指标 以测量 延迟和吞吐量。

配置概览

可在 GitHub 公开仓库[2] 中找到所有配置文件。

这不是第一次使用 Nginx，所以 基于以往的反馈优化了 Nginx 的配置，以确保测试结果尽可能合理。

需要注意的是，Nginx 默认不对后端启用 Keep-Alive 连接，因此必须 显式启用 keepalive 指令 并添加一些相关的 HTTP 头部信息。

对于 HAProxy，使用了 最基本的默认配置[3]，并且：

• 配置了 TLS 证书
• 使用了 两个后端服务器

至于 Traefik，配置[4]基本与 HAProxy 相同。

为了保证基准测试的准确性，为所有代理服务器禁用了访问日志（Access Logs）。

测试过程

整个测试持续了大约 2.5 小时，但我将其压缩到了短短几分钟的视频中。

在测试过程中，会注意到 某个代理服务器很快就崩溃了，因此将其从 监控面板（Dashboard） 中移除，直到测试结束。

让我们再运行 一分钟，然后来逐一分析每个图表的结果。

测试结果

吞吐量（Requests per Second）

坦白说， 没想到 HAProxy 的表现会比 Nginx 好这么多。

• Traefik 仅达到 22,000 请求/秒
• Nginx 约为 37,000 请求/秒（与之前所有的基准测试结果一致）
• HAProxy 达到了 76,000 请求/秒，创下了代理服务器的新纪录 （不过也许(要加个限定条件) 除了Pingora，但它更像是一个库，而不是独立的代理服务器）

延迟（Latency）

在 延迟测试 中，HAProxy 再次优于其他代理服务器。
延迟越低，用户体验越好，比如 网页加载速度会更快。

CPU 使用率（CPU Usage）

Nginx 在启用 TLS 时，在 CPU 使用率达到 80% 左右时崩溃。

这 不是由于文件描述符（File Descriptors）问题，而是一种 非常一致的行为，在许多其他测试中都观察到了这一现象，但仅在 Nginx 启用 TLS 时才会发生。

如果禁用 TLS，Nginx 的性能会 好得多。

后端应用的 CPU 使用率（Backend CPU Usage）

我们可以观察到一个相似的模式：

当某个代理服务器开始退化（性能下降）时，它向后端应用程序转发的流量会减少。

可用性（Availability）或错误率（Error Rate）

可用性指的是 成功请求与失败请求的比率：

• 成功请求：状态码 200 和 300
• 失败请求：状态码 400 及以上

网络传输流量（Network Traffic）

此项指标衡量的是网络流量的传输情况，包括：

• 向客户端的流量
• 向后端应用程序的流量

由于不同的代理服务器可能 默认使用不同的压缩级别和设置，所以它们的流量消耗可能会有所不同。

总结与后续计划

老实说， 没想到 HAProxy 的性能会全面超越 Nginx。
在实际应用中， 并不会直接使用独立的反向代理，而是使用 基于这些代理的 Ingress 控制器。

因此，在 未来的视频 中，会测试 Nginx Ingress 控制器 和 HAProxy Ingress 控制器 之间的 性能对比。