了解现代 WordPress 服务器堆栈

你还记得你什么时候可以只用一个 Apache 服务器和 PHP 运行一个“快速”的 WordPress 网站吗？ 是的，那是那些日子！ 那时的事情要简单得多。

现在，一切都必须以闪电般的速度加载！ 访问者对加载时间的期望与以往不同。 缓慢的网站可能会对您或您的客户产生严重影响。

关于 SmashingMag 的进一步阅读：

• 正确的 WordPress 文件系统权限和所有权
• 轻松移动 WordPress 网站
• 如何使用 MAMP 在本地开发 WordPress
• 使用 WordPress 自己动手做缓存方法

因此， WordPress 服务器堆栈多年来必须不断发展，以跟上这种对速度的需求。 作为这种演变的一部分，必须在其发动机中添加一些齿轮。 一些较旧的齿轮也必须更换。

结果是，今天的 WordPress 服务器堆栈看起来与几年前完全不同。 为了更好地理解它，我们将详细探索这个新堆栈。 您将看到各个部分如何组合在一起以快速构建 WordPress 网站。

概述

在深入研究之前，让我们缩小并查看大图。 这个新的 WordPress 服务器堆栈是什么样的？ 好吧，这是答案：

上图很好地概述了现代 WordPress 服务器堆栈的外观。 在高层次上，我们可以将正在发生的事情分为三个方面：

• 浏览器和 WordPress 之间的请求-响应周期；
• WordPress（这是 PHP 运行时执行的脚本）；
• WordPress 和 MySQL 数据库之间的查询-结果循环。

现代 WordPress 服务器堆栈的作用就是优化这三个方面。 这些优化使一切加载速度更快。 最好的部分是有几种方法可以做到这一点。 （耶！）

在大多数情况下，这些优化涉及在您的服务器上安装新服务。 有时，这些服务需要插件的帮助才能与 WordPress 进行交互。 有时您只需安装一个插件就可以摆脱困境。 您将在本文中看到许多不同的选项。

请求-响应周期

一切从浏览器开始。 假设您要查看modern.wordpress-stack.org的主页。 您的浏览器将首先向托管它的 Web 服务器发送 HTTP 请求。 在另一端，Web 服务器将接收您的请求并将其转换为 HTTP 响应。

第一个响应应该始终是modern.wordpress-stack.org主页的HTML 内容（除非出现错误）。 但是，您的浏览器的工作还没有完成。 不，该主页仍然需要更多文件，最常见的是 CSS、JavaScript 和图像文件。

因此，浏览器将发送对这些文件的请求。 Web 服务器将响应请求的文件（同样，只要没有错误）。 这个循环将一直持续到浏览器有足够的信息来呈现主页。 这个循环发生得越快，网站加载的速度就越快。

现在，这是一个明显的简化，但它是大多数 WordPress 网站的工作方式。

优化请求-响应周期

好吧，这给我们带来了一个显而易见的问题，我们如何让 Web 服务器更快地执行这个循环？ 这是一个很好的问题，也是现代 WordPress 服务器堆栈存在的部分原因。

堆栈的存在是因为您不能仅仅让 Web 服务器更快。 Web 服务器也是一个调度程序。 它可以接收请求并将其转发给其他服务。

这些其他服务通常是这个请求-响应周期的瓶颈。 对于 WordPress，这个瓶颈是 PHP，这就是为什么优化请求-响应周期归结为两件事。 我们希望网络服务器：

• 接收尽可能少的请求，
• 向 PHP 转发尽可能少的请求。

现代 WordPress 服务器堆栈专注于最后一个。 它希望向 PHP 转发尽可能少的请求。 这将是优化堆栈的主要目标。

我们专注于第二个目标，因为堆栈不能对第一个目标做太多事情； 它对其没有直接影响。 第二个问题可以通过 Web 服务器的配置或现代开发技术来解决。

请求-响应周期的堆栈元素

那么，哪些栈元素可以帮助我们减少转发给 PHP 的请求呢？ 嗯，特别是两个堆栈元素将帮助我们实现这个目标：Web 服务器和 HTTP 缓存。

网络服务器

我们已经谈论了很多关于 Web 服务器的内容。 Web 服务器领域有三大玩家：

• 阿帕奇
• 互联网信息服务 (IIS)
• nginx

这些共同构成了 Internet 上 Web 服务器市场份额的 90% 以上。 我们将专注于 Apache 和 nginx。 虽然 IIS 可用于运行 WordPress，但它并不常见，因为它仅适用于 Windows，而且大多数 WordPress 服务器使用 Linux。

这给我们留下了 Apache 和 nginx。 在 WordPress 的整个生命周期中，Apache 一直是推荐的 Web 服务器。 我们有 LAMP 堆栈（Linux、Apache、MySQL 和 PHP），它在计算机和服务器上运行 WordPress。

但在幕后，事情正在发生变化。 镇上来了一个新玩家，它的名字叫 nginx。 Automattic 和 WordPress.com 自 2008 年以来一直在使用它。它是运行最大比例的高流量网站（其中很多都运行 WordPress）的 Web 服务器。 这就是为什么许多高端托管公司和顶级 WordPress 代理使用它作为他们的网络服务器的原因。

并不是说 Apache 是一个糟糕的 Web 服务器。 有 Apache 专家可以使其在大量流量下运行良好。 开箱即用或使用标准 WordPress 配置时，它的效果并不好。

同时，nginx 的唯一目的是处理大量流量。 这就是 Igor Sysoev 在 Rambler 工作时开始这个项目的原因。

nginx 更好地处理更多流量的原因之一是它使用 FastCGI 与 PHP 进行通信。 什么是 FastCGI？ 它是一种让 PHP 作为独立于 Web 服务器的服务运行的协议。

默认情况下，Apache 不这样做。 每次 Web 服务器收到请求时，它都需要启动 PHP 运行时进程——即使是图像、JavaScript 和 CSS。 这减少了服务器可以处理的请求数量以及处理它们的速度。

这违背了我们之前看到的现代 WordPress 服务器堆栈的目标之一。 堆栈需要保持请求-响应循环时间尽可能短。 为每个请求加载 PHP，即使它不需要它，也违背了这个目标。 因此，如果您使用 Apache，请查看 FastCGI。

HTTP/2是您应该了解的另一个重要的 Web 服务器功能。 它是 HTTP 的下一个版本，支持我们整个请求-响应周期的协议。

在 HTTP/2 到来之前，浏览器只能与 Web 服务器建立六个连接。 每个连接一次只能处理一个请求。 因此，在实践中，请求-响应周期的上限为每个周期六个请求。

这是一个真正的问题。 大多数网站在其周期中有几十个请求。 开发人员和系统管理员找到了解决此限制的巧妙方法。

一种更广为人知的解决方法是结合 CSS 和 JavaScript 文件的做法。 在理想情况下，这会将对 CSS 和 JavaScript 文件的请求总数减少到两个：一个用于 JavaScript，一个用于 CSS。

对于 HTTP/2，这不是必需的。 HTTP/2 允许每个连接无限数量的请求。 这允许在初始 HTML 响应之后的所有额外请求同时发生。

这具有巨大的性能影响。 许多优化服务器堆栈的工作都集中在请求-响应周期上。 通过将周期数减少到少数几个，HTTP/2 为我们完成了大量工作。

HTTP 缓存

现代 WordPress 服务器堆栈中最重要的部分是 HTTP 缓存。 在 WordPress 世界中，我们也称此页面缓存。 HTTP 缓存的目的是缓存对请求的响应。 这是什么意思？

好吧，让我们回到我们之前的例子。 浏览器发送一个对modern.wordpress-stack.org主页的请求，Web 服务器接收该请求并将其转发给 PHP。

这种情况的问题是 Web 服务器是愚蠢的。 它总是将它收到的所有请求转发给 PHP——不管大多数请求是否会产生相同的响应。

这正是访问者未登录时发生的情况。对于 Web 服务器来说，它们都是不同的请求，但它并不关心。 它会将它们全部转发给 PHP，PHP 将为所有这些生成相同的响应。

这太可怕了！ 正如我们之前看到的，PHP 是我们请求-响应周期的真正瓶颈。 在收到初始主页响应之前，您的浏览器无法发送其后续请求。 默认情况下，我们不能让 Web 服务器将所有内容都转发到 PHP。

这就是 HTTP 缓存的用武之地。它位于 Web 服务器和 PHP 之间。 它的工作是检查 Web 服务器接收到的每个请求并查找缓存的响应。 如果没有，它会将请求转发给 PHP，然后缓存 PHP 生成的响应。

这大大减少了请求-响应周期时间，使网站加载速度更快。 它还允许 Web 服务器处理更多并发请求而不会崩溃。

HTTP缓存的不同风格

在这一点上，你应该想知道，“我怎样才能让这个宝贝尽快在我的服务器上？！” 好消息是在 WordPress 服务器上安装 HTTP 缓存非常容易。 它是选项范围最广的组件。

安装页面缓存插件

最简单的方法是安装页面缓存插件。 您有几个选项可供选择：

• 蝙蝠缓存
• 超高速缓存
• 缓存启动器
• WP火箭
• WP 超级缓存
• W3 总缓存

除了 WP Rocket 之外的所有插件都可以作为 WordPress 目录中的免费插件使用。 因此，您可以安装一个并立即进行测试。 话虽如此，在四个插件中，最好的一个是 WP Rocket。 虽然它是一个付费插件，但它所做的不仅仅是创建一个 HTTP 缓存。 这些其他好处放大了 HTTP 缓存所做的工作。

页面缓存插件如何工作？

所有这些插件都利用了 WordPress 为缓存提供的插件。 这个缓存插件允许插件在 WordPress 内部创建一个 HTTP 缓存系统。 缓存插件需要两件事才能工作。

首先， advanced-cache.php文件需要在wp-content文件夹中。 那是实际的文件。 但与大多数 WordPress 插件不同，这个插件默认情况下不会启动。 WordPress 还需要WP_CACHE常量为true才能加载插件。 在大多数情况下，您可以在wp-config.php中进行设置。

上图显示了当您使用缓存插件启用插件时会发生什么。 WordPress 在加载过程中加载wp-settings.php中的插件。 这已经足够早了，WordPress 还没有做任何耗时的事情。

然后缓存插件将检查它是否已经缓存了对请求的响应。 如果有，它将返回缓存的响应。 如果没有，它将打开 PHP 输出缓冲，并且 WordPress 将继续加载。

现在，输出缓冲是一个有趣的系统。 它的作用是在字符串变量中捕获 PHP 脚本的所有输出，直到发生以下两种情况之一：

• 您告诉 PHP 使用内置函数之一停止缓冲其输出，
• PHP 脚本完成并需要向浏览器返回响应。

缓存插件依赖于后一种情况。 它希望 WordPress 完成它的工作，然后在 PHP 将其发送回浏览器之前缓存整个输出。 您可以在下图中看到该过程。

让 Web 服务器执行此操作

下一个选项是在 Web 服务器级别添加 HTTP 缓存。 它的工作方式是 Web 服务器将缓存对转发到 PHP 的请求的所有响应。 这个解决方案比缓存插件更好，因为它根本不需要接触 PHP。

上图概述了 Web 服务器中的情况。 Web 服务器接收请求并检查 HTTP 缓存。 如果响应已被缓存，HTTP 缓存会将其发回。

否则，它会将请求转发给 PHP 模块（通常是 FastCGI）。 它将请求传递给 WordPress，以便它可以生成响应。 然后，HTTP 缓存模块将在返回的路上缓存该响应。

Apache 和 nginx 都具有添加 HTTP 缓存系统的能力。 nginx 是内置的。Apache 是一个单独的模块，您需要将其添加到 Apache 安装中。

关于如何将 Apache 模块与 PHP 或 WordPress 一起使用的信息并不多。 这可能是因为它在 Apache 人群中不受欢迎，或者可能是因为它存在一些问题。 至少有一个长期存在的问题仍然存在。

同时，nginx HTTP 缓存系统是健壮且有据可查的。 您可以将其用作普通的 HTTP 缓存或用作较小但有效的微缓存。 这只是 nginx 成为当今首选 Web 服务器的另一个原因。

将清漆添加到堆栈

什么是清漆？ 它是一个专用的 HTTP 缓存服务器（或者，正如其开发人员喜欢的那样，它是 HTTP 加速器）。 大多数高流量网站和高级托管公司都使用它作为他们的 HTTP 缓存解决方案。

他们使用它是因为它功能强大并且提供了最大的灵活性。 Varnish 有自己的配置语言，称为 VCL。 它使您可以控制缓存过程的每个元素。 Varnish 还附带了许多工具，用于分析缓存在做什么以及它是如何执行的。

这些是使用它与仅使用内置 Web 服务器 HTTP 缓存之间的主要区别。 内置的 Web 服务器 HTTP 缓存性能超级好，但也非常基础。 除了几个配置选项之外，您没有太多控制权。

然而，这种能力和灵活性是有代价的。 Varnish 也是最复杂的 HTTP 缓存选项。 它除了缓存 HTTP 响应什么都不做。 它不处理大多数 WordPress 开发人员想要（或应该想要）的 SSL 终止。 这意味着当我们使用现代 WordPress 服务器堆栈时，它会变得更加复杂。

上图说明了这种额外的复杂性。 现在，我们的 WordPress 服务器堆栈中还有两个组件：Varnish 和反向代理。

反向代理可以克服 Varnish 对 SSL 的限制。 它位于 Varnish 前面并解密我们的服务器收到的请求。 您也可以将这种类型的反向代理称为 SSL 终止代理。 然后代理将这些解密的请求发送给 Varnish 进行处理。

一旦请求到达 Varnish，VCL 配置文件就会启动。它们是 Varnish 的大脑。 例如，他们告诉它如何：

• 分析、清理和修改传入请求；
• 寻找缓存的响应；
• 分析、清理和修改来自 WordPress 的返回响应；
• 缓存这些返回的响应；
• 处理从缓存中删除一个或多个响应的请求。

最后一个尤为重要。 Varnish 没有办法知道 WordPress 何时要从缓存中删除页面。 因此，默认情况下，如果您对帖子进行更改并更新它，访问者将继续看到相同的缓存页面。 幸运的是，有一个插件可以从 Varnish 缓存中删除页面。

WordPress

好的，我们对modern.wordpress-stack.org主页的请求已经访问了WordPress。 它经历了我们刚刚介绍的请求-响应周期。 HTTP 缓存尽其所能找到要发回的 HTTP 响应。

但是没有缓存的 HTTP 响应发送回浏览器。 那时，HTTP 缓存别无选择。 它必须将 HTTP 请求转发给 WordPress。

现在一切都在 WordPress 手中。 WordPress 必须将我们的 HTTP 请求转换为 HTTP 响应并将其发送回 HTTP 缓存。 正如我们之前看到的，这是我们整个现代 WordPress 服务器堆栈的主要瓶颈。

造成这种瓶颈的原因有两个。 WordPress 有很多 PHP 代码要执行。 这很耗时，而且 PHP 做的越慢，花费的时间就越长。

另一个瓶颈是 WordPress 需要执行的数据库查询。 数据库查询是昂贵的操作。 数量越多，WordPress 的速度就越慢。 这将是查询结果循环的最后一部分的重点。

优化 PHP 运行时

让我们回到 PHP。 目前，WordPress 的最低要求为 PHP 5.2。 这个版本的 PHP 已经快 10 年了！ （PHP 团队在 2011 年停止支持它。）

PHP 团队这些年来一直没有闲着。 已经进行了许多性能改进，尤其是在过去几年中。 让我们看看你现在可以做些什么来优化它。

使用最新版本的 PHP

您可以做的最简单的事情是升级您的 PHP 版本。 版本 5.4、5.5 和 5.6 都看到了性能改进。 最大的改进是从 5.3 到 5.4。 切换到它使 WordPress 的性能大大提高。

安装操作码缓存

操作码缓存是另一种加速 PHP 的方法。 作为一种服务器端脚本语言，PHP 有一个很大的缺陷：每次执行时都需要编译一个 PHP 脚本。

解决这个问题的方法是缓存编译后的 PHP 代码。 这样，PHP 就不必在每次执行时都编译它。 这是操作码缓存的工作。

在 PHP 5.5 之前，PHP 没有捆绑操作码缓存。 您必须自己在服务器上安装它。 这是使用更新版本的 PHP 更好的另一个原因。

切换到下一代编译器

您可以做的最后一件事是切换到两个下一代编译器之一：Facebook 的 HHVM 或 PHP 7，最新版本的 PHP。 （为什么选择 PHP 7？说来话长。）

Facebook 和 PHP 团队从头开始构建了这两个编译器。 他们想利用更现代的编译策略。 HHVM 使用即时编译，而 PHP 7 使用提前编译。 两者都比优秀的 PHP 5 提供了令人难以置信的性能改进。

HHVM 是几年前第一个出现的。 许多顶级主机都使用它取得了很大的成功，将其作为主要的 PHP 编译器。

不过，值得强调的是，HHVM 不是官方的 PHP 编译器。 它不是 100% 与 PHP 兼容。 原因是 HHVM 不仅仅是为了支持 PHP 而设计的。 它也是 Facebook 的 Hack 编程语言的编译器。

PHP 7 是官方的 PHP 编译器。 它已经很久没有出现了。 PHP 团队于 2015 年 12 月发布了它。这并没有阻止一些 WordPress 托管公司已经支持它。

好消息是 WordPress 本身 100% 兼容这两种编译器！ 坏消息是，并非所有插件和主题都是如此，因为 WordPress 的最低 PHP 版本仍然是 5.2。

没有什么会迫使作者让他们的插件或主题与这些编译器一起工作。 所以，你不能全力以赴。 您的堆栈应始终回退到 PHP 5。

查询-结果循环

此时，PHP 运行时正在遍历所有 WordPress PHP 文件并执行它们。 但是，这些 WordPress PHP 文件不包含任何数据。 它们仅包含 WordPress 代码。

问题是 WordPress 将其所有数据存储在 MySQL 数据库中。 因此，要获得它，PHP 运行时需要查询该数据库。 MySQL 服务器返回该查询的结果，然后 PHP 运行时继续执行 WordPress PHP 文件……嗯，也就是说，直到它再次需要数据。

这种来回可能会发生几十次到几百次。 （如果是后者，您可能想与您的开发人员交谈！）这就是为什么它是一个主要瓶颈。

优化查询-结果周期

这里的优化目标是通过 PHP 加快 WordPress 文件的执行时间。 这就是数据库查询有问题的地方。 它们往往比仅仅运行普通的 PHP 代码需要更多的时间（除非你的代码正在做一些令人发指的事情）。

解决此问题的明显方法是减少 WordPress 需要执行的查询数量。 这总是值得的！ 但这不是现代 WordPress 服务器堆栈可以提供的帮助。

我们可能无法减少 WordPress 的查询数量，但我们也并非没有选择。 堆栈仍然有两种方法可以帮助我们优化查询结果周期。 它可以首先减少对数据库的查询次数。 对于那些进入数据库的查询，它可以减少运行它们所需的时间。

这两个选项都是为了做同样的事情：让 PHP 尽可能少地等待来自数据库的结果，这将使 WordPress 本身更快。

查询-结果循环的堆栈元素

让我们看看查询结果循环中涉及的不同堆栈元素。 堆栈的这一部分不太复杂。 但它仍然涉及不止一个组件——即 MySQL 数据库服务器和对象缓存。

MySQL 数据库服务器

几年前，MySQL 数据库服务器对每个人来说都意味着同样的事情。 这是一台安装了 MySQL 服务器的服务器。 但近年来情况发生了很大变化。

各个团体对甲骨文管理 MySQL 项目的方式不满意。 因此，每个小组都对其进行了分叉并创建了自己的版本，您可以改为“加入”。 结果是现在有几个 MySQL 数据库服务器。

新的“官方” MySQL 服务器是 MariaDB 服务器。 它是社区开发的 MySQL 服务器版本。 社区计划保持与 MySQL 服务器项目的完全兼容性。

MySQL 的另一个流行替代品是 Percona 服务器。 与 MariaDB 不同，Percona 更像是 MySQL 的一个分支。 它的开发者并不反对 MySQL 项目本身。 他们只想专注于提高 MySQL 的性能。 MariaDB 团队后来将其中一些性能改进合并到 MariaDB 项目中。

在一天结束时，您可以选择您喜欢的那个。 Percona 服务器和 MariaDB 服务器之间的性能没有差异（无论如何对我们大多数人来说）。 它们的性能都比 MySQL 好。 然而，Percona 确实与 Oracle 项目保持了更密切的兼容性。

影响性能的是 WordPress 数据库使用的存储引擎。 存储引擎控制数据库服务器如何管理它存储的数据。 您还可以为每个数据库表设置不同的存储引擎； 您不必为整个数据库使用相同的数据库。

数据库服务器有多个存储引擎。 我们不会查看所有这些。 我们只对两个感兴趣：InnoDB 和 MyISAM。

默认情况下，WordPress 使用默认的 MySQL 数据库引擎。 在 MySQL 5.5 之前，该引擎是 MyISAM。 如果您运行一个小型 WordPress 网站，那么 MyISAM 就可以了。 一旦网站规模扩大，MyISAM 就会遇到性能问题。 那时，InnoDB 是数据库引擎的唯一选择。

InnoDB 的唯一问题是它需要进行一些调整才能发挥最佳性能。 如果您正在运行大型数据库服务器，则可能需要进行一些调整。 对我们来说幸运的是，有一个工具可以帮助解决这个问题。

MySQLTuner 是一个分析数据库服务器的小脚本。 它将生成报告并为您提供调整建议。

对象缓存

优化查询结果周期的工作首当其冲的是对象缓存。 对象缓存的工作是存储获取或生成耗时的数据。 正如您可能猜到的那样，数据库查询是一个完美的候选者。

WordPress 大量使用对象缓存。 假设您使用get_option从数据库中获取选项。 WordPress 只会在数据库中查询该选项一次。 下次有人需要它时，它不会再次查询它。

相反，WordPress 将从对象缓存中获取查询结果。 这是 WordPress 为减少需要进行的数据库查询而采取的主动步骤。 但这不是一个万无一失的解决方案。

虽然 WordPress 会尽力利用对象缓存，但插件或主题并非必须如此。 如果一个插件或主题进行了大量的数据库查询并且没有缓存结果，则堆栈对此无能为力。

在这种情况下，大多数数据库查询将来自 WordPress 本身。 因此，您将从 WordPress 对对象缓存的内置使用中获得极大的帮助。 这就是为什么它是现代 WordPress 服务器堆栈的重要元素。

现在，对象缓存的一个问题是它不会默认保存它存储的数据。 它只是在 PHP 执行所有 WordPress 文件时将数据存储在内存中。 但是一旦 PHP 进程终止，它存储在内存中的所有数据都会被清除。

这一点都不理想。 对象缓存可以长时间保持有效，因此您不想将其限制为单个请求。 解决方案是使用持久对象缓存。

持久对象缓存通常以插件的形式出现。 该插件将利用object-cache.php插件来完成其工作。 这个插件允许插件作者更改对象缓存的默认行为。

然后插件将对象缓存连接到持久数据存储。 他们通过替换默认对象缓存的获取和保存功能来做到这一点。 对象缓存不是将数据保存和获取到内存，而是从该存储中进行。

持久对象缓存插件

如今，有两种流行的用于持久对象缓存的数据存储选项：

• 内存缓存（插件）
• Redis（插件）

这两个数据存储都使用 RAM 进行存储，这使得它们快如闪电。 事实上，它们的性能与默认对象缓存的性能相当。

唯一的问题是它们没有预装在服务器上。 他们的 PHP 扩展也没有（Redis 是可选的）。 您需要先安装一个，然后才能使用相应的 WordPress 插件。

你应该安装哪一个？ 实际上，对于对象缓存，两者之间没有太大区别。 过去，流行的选项是 Memcached。 在过去的几年里，这种情况发生了变化。 Redis 添加了许多特性，使其成为对象缓存的首选。

获得您自己的现代 WordPress 服务器

那么，如何获得自己的服务器呢？ 显而易见的方法是从顶级 WordPress 托管公司获得一个。 这些公司希望保持在 WordPress 托管业务的最前沿，这促使他们采用最新的突破和技术。

但是，如果您想要一个而不破坏银行怎么办？ 任何愿意自己动手​​并为托管支付更少费用的人都可以使用一些工具。 让我们看看他们。

WordPress 的 DebOps

DebOps for WordPress 是我为帮助任何人构建现代 WordPress 服务器而构建的工具。 它的使命是让社区中的任何人都可以使用现代 WordPress 服务器堆栈。 这就是为什么我试图让它尽可能易于使用。 您不需要任何系统管理知识即可使用它。

DebOps for WordPress 使用以下内容配置服务器：

• HHVM（直到 PHP 7 成为官方 Linux 存储库）
• 玛丽亚数据库
• nginx
• 雷迪斯
• 漆

该工具不仅仅是使用最新技术配置服务器。 它还负责为您保护服务器。 这是人们在管理自己的服务器时经常忽略的事情。

易引擎

EasyEngine 是一个命令行工具，旨在帮助您在服务器上设置 WordPress 网站。 EasyEngine 的伟大之处在于它的灵活性：您可以使用它来设置我们迄今为止研究过的几乎任何服务器技术组合。

例如，它允许您使用 HHVM 或 PHP 7 设置服务器。它允许您在 Memcached 和 Redis 之间选择用于持久数据存储。 它允许您安装管理员工具，例如 phpMyAdmin。

在创建 WordPress 网站时，它还提供了大量选项。 你可以告诉它使用插件或 nginx 设置一个带有 HTTP 缓存的网站。 所有这些灵活性是 EasyEngine 如此受欢迎的工具的原因。

格子

Trellis 是由 Roots 开发的工具。 与 DebOps 一样，它使用一组特定的服务器技术配置服务器：

• 玛丽亚数据库
• 内存缓存
• nginx
• nginx HTTP 缓存（可选）
• PHP 7

关于 Trellis 的一件事是它与 Bedrock 的关系，Bedrock 是 Roots 构建的另一种工具。 Bedrock 是围绕“十二要素应用程序”原则构建 WordPress 网站的样板。

Roots 团队创建了 Trellis，以使人们能够配置使用基岩结构 WordPress 网站的服务器。 您不能在正常的 WordPress 安装中使用它，因此请记住这一点。

时代变了

如您所见，如今 WordPress 服务器有更多的移动部件！ 但这并不一定是绝望的原因。 它并不像看起来那么糟糕，因为您并不总是需要使用所有部件。

这就是为什么本文的大部分内容都在讨论这些部分如何协同工作。 关键是让你能够做出自己的决定。 使用这些知识来决定您需要使用哪些部件以及何时使用。 这样，您也将拥有一个快速的 WordPress 网站。