性能比拼: Nginx vs Caddy
本内容是对知名性能评测博主 Anton Putra Nginx vs Caddy Performance 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准
引言
在本期视频中，我们将对比 Nginx 和 Caddy---一个用 Go 编写的 Web 服务器和反向代理。
在第一个测试中，我们会使用 Nginx 和 Caddy 通过 HTTPS 提供静态网站服务，并在两个服务器上启用默认压缩。我们重点关注的是延迟，使用 p99 百分位进行衡量。吞吐量方面，我们会查看每个 Web 服务器可以处理的请求数。为评估资源饱和度，我们将监控 CPU 与内存相对于整台虚拟机的使用情况，以及网络流量。最后，我们还会测量每个 Web 服务器的错误率或可用性。
在第二个测试中，我们会将 Nginx 和 Caddy 用作反向代理和负载均衡器，将流量分发给后端应用。此外，我们也会统计这些应用的 CPU 和内存使用情况。
我使用 AWS 来运行所有测试，并根据不同的工作负载选择最新的 EC2 实例。例如，在这个视频中，我为 Web 服务器配置了 m7a.large 实例，后端应用使用同样的 EC2 类型。我还设置了一个由 Graviton 实例组成的 EKS 集群，用来运行客户端并生成负载。同时使用 Route 53 创建私有托管区域，用于服务发现。每次基准测试运行数小时，通常每次测试的花费在 20 到 50 美元之间。
测试设计
我使用 Terraform 创建 VPC 及测试所需的所有网络组件。
在第一个测试中，我使用基于 React 的 JavaScript 框架 Next.js 来生成一个简单的网站，并将其编译为 HTML、CSS 和 JavaScript 文件。然后我为每个 Web 服务器创建一个大型 EC2 实例（2 个 CPU 和 8 GB 内存），并将网站上传至每台服务器。同时，我创建了一个自签名的证书颁发机构，并为 Nginx 和 Caddy 签发证书。
为生成负载，我创建一个 EKS 集群，并使用 Kubernetes job 为每台 Web 服务器部署约 20 个 pod。为每个客户端提供证书以认证访问 Web 服务器。这种设置很常见：两个服务器都使用压缩服务静态内容，并通过 HTTPS 提供安全传输。TLS 证书还允许我们从 HTTP/1 升级到更高效的二进制协议 HTTP/2。
在第二个测试中，我为每台服务器配置了两个额外的 EC2 实例，作为后端应用，实例类型与前面相同。此测试中，每台服务器被配置为反向代理和负载均衡器，将流量分发到后端应用。由于负载较小，此测试未启用压缩。每个应用向客户端返回硬编码数据。此外，我配置了代理传递原始客户端 IP 地址，使用的是 X-Forwarded-For 头。
当反向代理接收到来自客户端的请求时，会终止该请求，并以自身 IP 作为源地址，向应用发起新的请求。如果你的应用需要获取客户端的真实 IP，可以使用 X-Forwarded-For 头或配置 proxy protocol。
配置概览
在之前与 Apache 的测试中，我主要使用 Nginx 的默认设置，这些设置已经很高效。但我收到 Melroy 的一个 Pull Request，包含了一些优化建议，于是在这次测试中应用了它们。我还做了一些额外的配置更改，并测试了不同的线程设置。
这些更改对第一个测试影响不大，但在第二个测试中显著提升了 Nginx 作为反向代理和负载均衡器的性能。配置中还包括 multi_accept 设置，并且我提高了系统允许打开的文件数限制。
在网站配置中，我只使用了 443 端口用于 HTTPS，并提供了我本地生成的证书和私钥。第二个测试中，我声明了一个上游服务，并使用默认的轮询算法将流量分发给后端应用。我也添加了 X-Forwarded-For 头，大致就是这些配置。源代码可在我的公共 GitHub 仓库中找到，链接会在视频描述中提供。
在之前的测试中，我使用的是最新稳定版本 1.26.2。这次测试使用的是主线分支的最新版本 1.27.2。
另一方面，我们来看 Caddy。据我所知，Caddy 最大的卖点是简单易用。如果你不想花时间配置 Nginx，可以选择 Caddy，它几乎能完成 Nginx 所能做的一切，但只需最少配置。这个 Web 服务器对初学者也很友好。根据官方文档，一个非常简单的配置就可以用于生产环境。
因此，我在测试中故意使用了默认的“生产”设置。
我为 Caddy 编译并使用了相同的网站，也启用了压缩。我提供了自己的证书和私钥，并使用 file_server 指令来提供网站服务。默认情况下，Caddy 的访问日志非常详细，为了公平比较，我使用了类似 Nginx 和 Apache 的日志格式，以减少文件系统负载。第二个测试中，我同样使用了最小配置，使用 reverse_proxy 设置。
所以从功能上看，这两个服务器都使用压缩和 HTTP/2 协议，并通过 HTTPS 提供服务。Caddy 使用的版本是 2.8.4。
第一个测试：Web 服务器
现在让我们开始第一个测试。对我来说，延迟和吞吐量是最重要的指标，当然还有可用性。
测试开始时，Nginx 在提供静态网站时延迟明显更低。从 CPU 使用率来看，你可以预测哪个 Web 服务器更容易先失败。内存使用方面，两者非常接近，约占 8GB 总内存的 6%。你还会注意到，Nginx 传输的网络数据稍多一些，主要是因为它的压缩级别略低。
在每秒约 4,000 个请求时，Caddy 的 CPU 使用率达到了 50%，从那时开始延迟开始上升。至于每个请求的“有效延迟”标准，需要根据你的使用场景和预期定义。在这个测试中，我使用的是 1 秒超时，超时后返回 408 状态码，这会影响服务的可用性。
当请求达到每秒约 8,000 个时，Caddy 在每秒请求数方面开始落后于 Nginx。此时出现了显著的延迟峰值，我怀疑这可能是 Go 的垃圾回收导致的，但也可能是别的原因。如果你有不同看法，欢迎告诉我。
在每秒约 10,000 个请求时，Caddy 的 CPU 使用率接近 100%，性能进一步下降。
本次测试中，Nginx 和 Caddy 部署在独立的虚拟机上，因此不存在 CPU 限流的问题。现在我们来看看优化后的 Nginx 最多能处理多少请求。虽然花了点时间，但最终 Nginx 达到了接近每秒 22,000 个请求，与之前 Apache 视频中的结果几乎一致，不过这次表现更加稳定。在上次测试中，Nginx 在达到 80% CPU 使用率后立即崩溃，而这次即使达到相同请求数仍能继续运行。
现在我们打开每张图表，查看整个测试持续时间。整个测试持续了大约 2 小时。
首先是每秒请求数图表---在 8,000 请求/秒时 Caddy 开始性能下降，最高约 10,000 请求/秒；而 Nginx 处理了超过两倍的请求，达到 22,000 请求/秒。
接着是 p99 延迟图表。Caddy 开始性能下降后延迟上升明显，但从测试一开始，Nginx 的延迟就更稳定，显著低于 Caddy。对于面向客户端的应用来说，低延迟能够提供更好的用户体验。
然后是两个 Web 服务器的 CPU 使用情况。Web 服务器是典型的 CPU 密集型应用，因此 CPU 使用率越低，通常意味着更好的响应速度和更高吞吐量。
接下来是内存使用图表。虽然有几次波动，但始终在 6% 到 8% 之间。因此，在这个测试中，内存并不是性能瓶颈。
然后是可用性图表。你可以看到测试后期错误率略有上升，但比例极小---每秒几千个请求中只有 1~2 个错误。你可能会好奇为什么 Caddy 没有错误？这是因为 Nginx 会尝试处理所有请求，而 Caddy 在过载时会拒绝新请求，因此不会产生超时错误。
最后是网络流量图表。在峰值时，Nginx 的吞吐量接近每秒 600MB，而 Caddy 只有一半不到。
如果你是初学者或 Web 开发者，不想花太多时间优化 Web 服务器，Caddy 是个不错的选择。如果你担心 TLS 证书管理，Caddy 也非常适合。但从性能来看，Nginx 明显更强，可以大幅降低运行成本。我估算使用 Nginx 可节省近一半的基础设施费用。最终选择权在你手中，如果是个人项目或少量用户，Caddy 完全能胜任。
第二个测试：反向代理
我们继续进行第二个测试。在这个测试中，我们将每个服务器作为反向代理和负载均衡器使用。
最初我很高兴看到 Caddy 表现优于 Nginx，但这种优势很快就消失了。当请求达到每秒 900 次，CPU 使用率仅为 12% 时，Caddy 的延迟就开始上升。相比之下，Nginx 的延迟保持平稳。
这个测试中让我最惊讶的是：为什么 Nginx 后端的应用承受了比其他代理更大的负载？之前 Apache 的测试中也出现了类似情况。如果你对此有见解，请告诉我。
这个测试中，Nginx 的内存使用稍高于 Caddy，但对于这种 CPU 密集型应用，内存影响不大。
当请求达到每秒约 10,000 次时，Caddy 出现了与上次类似的延迟问题。我怀疑也是垃圾回收引起的，但欢迎你提供其他想法。
当请求达到每秒 14,000 次时，Caddy 的 CPU 使用率几乎达到 100%，无法处理更多请求，延迟也开始明显上升。接下来我们看看 Nginx 能处理多少请求。
整个测试持续近 3 小时，Nginx 最终达到了近 27,000 请求/秒的吞吐量，比 Apache 测试中的结果还高。可见，如果打算将 Nginx 用作反向代理，务必要进行优化，而不是依赖默认配置。
我们接着查看每个图表：
- 吞吐量：Caddy 最多处理约 14,000 请求/秒，而 Nginx 达到约 27,000 请求/秒。
- 延迟图表：测试初期 Caddy 表现稍好，但很快失去优势。
- CPU 使用情况
- 内存使用情况
- 可用性图表：Caddy 的可用性在某些阶段甚至降至 42%，而 Nginx 几乎保持在 99.99%。
- 网络流量图表
- 反向代理后应用的 CPU 使用情况：Nginx 后的应用 CPU 使用率异常高，请告诉我你对此的看法。
- 反向代理后应用的内存使用情况
结论：我认为 Caddy 是非常适合 Web 开发者或初学者的 Web 服务器。但如果你开始搭建负载均衡和反向代理，说明你已经有一定流量，应开始考虑架构优化并深入学习 Web 服务器和代理。此时，Nginx 提供更高吞吐量和更低延迟，运行成本更低。因此，与其使用 Caddy，不如选择 Nginx 或其他更高效的代理。