在快速加载 WordPress 网站时，缓存至关重要。优化的页面缓存可以显着缩短访问者的加载时间并减少服务器上的负载。这是一个双赢的局面！然而，并不是所有的页面缓存解决方案都是平等的。在 WordPress.org 上对“缓存”进行简单的插件搜索将返回数千个结果。但是，在页面缓存您的网站时，WordPress 缓存插件并不是唯一可用的选项。事实上，WordPress 缓存插件的性能通常不如 Varnish 或 Nginx FastCGI 等基于服务器的解决方案。
在这篇文章中，我们将比较 Varnish 与 Nginx FastCGI 缓存，看看哪个会脱颖而出。在此过程中，我们还将在未启用缓存的情况下对 WordPress 进行基准测试，并将 WordPress 缓存插件加入其中以进行良好的衡量。我选择了 Simple Cache，因为顾名思义，它的设置很简单。
您可能对堆栈很熟悉，但这里有一张图表作为复习：
Varnish vs Nginx
在我们开始工作并深入进行基准测试之前，让我们回顾一下我们将要比较的每项技术以及我们为什么将它们用于缓存。
Varnish Cache 是一个开源前端加速器，用于 Web 或缓存反向代理。它安装在处理 HTTP 请求并设置缓存响应内容的 Web 服务器前面。它的设计速度也非常快，根据官方文档，它可以将内容的交付时间加快 300 到 1000 倍，具体取决于架构。
Nginx 的主要功能是充当 Web 服务器。它可以处理反向代理、缓存、媒体流，甚至可以充当负载均衡器等。 Nginx 多年来不断发展壮大，最初是一个简单的 Web 服务器，旨在实现最大的稳定性和性能。今天，我们将把我们的服务器配置为一个将请求传递给 PHP-FPM 的 Web 服务器。 FastCGI（用于在 Nginx 和 PHP-FPM 之间进行通信的协议）缓存将配置为将来自 PHP-FPM 的响应缓存为静态 HTML 文件，Nginx 可以直接为后续请求提供服务。
如您所见，它们在功能上并不完全相同。 Varnish 是专门围绕缓存设计的，而 Nginx 是一个 Web 服务器，能够使用隐藏在引擎盖下的缓存。虽然 Nginx 不直接依赖其他任何东西，但 Varnish 确实需要像 Apache 或 Nginx 这样的 Web 服务器才能运行。
我们如何对缓存进行基准测试？
ApacheBench 是由 Apache Software Foundation 设计的 CLI 工具，最初是为了测试 Apache 的性能而创建的。
本文中的所有测试都将使用相同的选项执行，除了测试没有配置缓存的 WordPress。这样做的原因是因为直接向 PHP 和 MySQL 发送这么多并发请求只会增加平均响应时间，这并不能公平地代表 PHP 的性能。
ab -n 10000 -c 100 https://siteunderload.com/
这模拟 10,000 个请求，并发 100 个请求。 这意味着，ApacheBench 将一次发送总共 10,000 个请求，每批 100 个。 对于非缓存版本，我将使用 20 个请求的并发。
运行 ApacheBench 将输出类似于以下的结果：
在本文中，我们主要关注每秒请求数和连接时间。 我们将每个测试总共执行 10 次，并使用平均值进行比较。
我们也只会对 HTTPS 进行基准测试，因为此时每个站点都应该使用它来提高性能，更不用说安全性了。 如今，HTTPS 无处不在，这主要归功于 Let's Encrypt，这是一件好事！
服务器信息
所有基准测试都将使用相同的服务器堆栈，该堆栈由以下软件组成：
- DigitalOcean 2GB
- Ubuntu 20.04
- PHP 7.4.14
- Nginx 1.18.0
- MariaDB 10.4.17
- Varnish 6.2.1
- WordPress 5.6, Twenty Twenty-One
我们使用 DigitalOcean 已经有一段时间了，但如果您有兴趣，我们还进行了一些测试，以找到最适合 WordPress 的服务器提供商。
当当前的一组基准测试不需要时，清漆将被完全禁用。 Nginx 将用于终止 HTTPS 请求，因为 Varnish 无法这样做。这将导致以下配置：
Nginx:443 > Varnish:80 > Nginx:8080
请注意，我们让 Nginx 作为代理服务器来终止 HTTPS。还有其他可用的代理来执行此功能，但我选择了 Nginx 以将移动部件的数量保持在最低限度。
我们将测试四种不同的场景：
- WordPress – No caching
- Simple Cache – Caching via a WordPress plugin
- FastCGI Cache – Nginx
- Varnish – Varnish using Nginx for HTTPS termination
每秒请求数
正如预期的那样，没有缓存的 WordPress 性能不佳，这是由于数据库服务器造成的瓶颈。 只需通过启用页面缓存将数据库服务器排除在外，请求就会增加近 10 倍。 Varnish 通过确保请求不必由 PHP 处理来进一步改进。 然而，在原始吞吐量（每秒请求数）方面，Varnish 远远落后于 Nginx，这可能是由于 Nginx HTTPS 终止的额外步骤。 单独使用 Nginx 可以实现最佳吞吐量。
平均响应时间
如果这些请求完成速度很慢，那么每秒的大量请求并不意味着什么，这就是为什么还要测量响应时间很重要的原因。平均响应时间是完成请求所需的总时间。
当服务器负载过重时，平均响应时间通常会增加。发生这种情况是因为服务器通常由于 CPU 或内存瓶颈而只能处理一定数量的并发连接。当超过此数量时，所有其他连接都将排队并在资源可用时进行处理。如果这些请求排队的时间过长，它们就会超时。
通常，请求生命周期中的活动部分越少，平均响应时间就越短。这就是 Nginx FastCGI 缓存性能如此出色的原因，因为它只需要从磁盘提供静态文件（由于 Linux 页面缓存，它可能会缓存在内存中）。对没有缓存的 WordPress 站点的请求将命中 Nginx、PHP 和后端的数据库服务器。使用缓存插件，您只需使用 Nginx 和 PHP。通过 Nginx FastCGI Cache 或 Varnish 进行页面缓存，您只需使用 Nginx 或 Varnish。
最后的想法
在比较 Varnish 和 Nginx FastCGI Cache 时，Nginx 显然是高性能的赢家。它不仅每秒能够处理更多请求，而且平均每个请求的处理速度快 59 毫秒。
性能并不是唯一的考虑因素，那么易于配置呢？ WordPress 插件通常名列前茅，不包括控制面板笨拙的 W3 Total Cache。虽然 Nginx FastCGI 缓存相对容易配置，但它需要服务器上的 sudo 权限。另一方面，由于需要 HTTPS 终止，Varnish 的设置要复杂得多。
如果 Varnish 不是最快的解决方案，也不是最难设置的，你到底为什么要选择它？很简单，在通过 Varnish 配置语言 (VCL) 处理更复杂的缓存失效规则方面，Varnish 仍然是最好的。但是，除非您要设置需要复杂缓存结构（如电子商务平台）的 Web 应用程序，或者提供大量动态内容并混合缓存，否则通常没有必要。
在 SpinupWP，我们选择更长的缓存持续时间（7 天）并在内容更新时清除整个缓存。我们发现这个解决方案更可靠，而不是试图准确地确定应该从缓存中清除哪些网页或页面，由于发布存档和分页，这可能会很快变得复杂。
考虑到所有这些，Nginx FastCGI 缓存仍然是我们首选的解决方案，这就是为什么我们几年前从我们的服务器中删除了 Varnish 而现在完全依赖于 Nginx。这也是我们设置通过 SpinupWP 配置的每台服务器的方式。
你用什么来缓存你的 WordPress 网站？请在下面的评论中告诉我们。
