Nginx + php-fpm 是否比 Apache + mod-php 快得多

Question

我有一个在 Apache 服务器上运行的基于 PHP 的 Web 应用程序，它在后端有大量的 php 处理。由于整体性能较低，我致力于提高应用程序的性能。首先，我采用了诸如客户端缓存、gzip 启用、js-css 缩小等技术，这些技术将性能提高到一个很好的扩展。

为了进一步提高性能，我想尝试一下服务器级别的改进。所以我尝试通过将应用程序托管在 Apache 和 Nginx 服务器上来比较应用程序的性能。

• Nginx 版本 - 1.0.15;
• Apache 版本 - 2.2.15；
• php版本-5.4.38；

在 Apache 中，我使用 Apache + mod-php，在 Nginx 中，我使用 Nginx + php-fpm 进行比较。正如大多数教程所解释的那样，我将 Nginx 工作人员的数量配置为等于处理器中的内核数量。我使用 jmeter 进行压力测试，以下是我可以从中生成的图表。

在所有这些图表中，x 轴是我发送的每个请求，y 轴​​是获取每个请求的响应的毫秒数。

访问登录页面

提交登录页面

访问主页

我只能在 1 秒内执行最多 100 个并发用户登录的测试，因为它在这之后在两个服务器设置中都开始丢弃请求。

与 Apache 相比，Nginx 的性能略有提升，但在我的所有服务器架构从 Apache 更改为 Nginx 的情况下，这并没有太大区别。当我观察服务器资源利用率时，我也没有发现 Nginx 和 Apache 之间有太大区别

当我进行其他人的比较时，我发现他们声称 Nginx 在并发访问方面要快得多，如下图所示。

http://www.eschrade.com/wp-content/uploads/2014/01/event-mpm-nginx.gif

但即使在 1 秒内有 100 个并发访问，我也无法观察到 Nginx 与 Apache 的任何主要性能差异。

以下是我的问题。

1. 由于内存和其他资源的有效利用，Nginx + php-fpm 是否应该比 Apache + mod-php 更快地执行服务器操作？
2. Nginx 是否只推荐用于服务器静态竞争而不推荐用于重型服务器操作站点？
3. 有没有更好的方法来配置 Nginx 以获得更多的性能提升？

Answer 1

Apache 使用传统的基于文件的方法来处理静态内容。这种传统方法有点过时，这就是为什么如果考虑到当今处理静态内容的高标准，它的性能会略低。另一方面，Apache Web 服务器更重视动态内容，它通过嵌入式处理器处理它们。动态内容由网络服务器执行，无需外部组件。

正是这种在内部处理动态内容的能力使 Apache 成为具有更多动态内容的 Web 应用程序的最佳性能 Web 服务器。来到 Nginx，Nginx 缺乏内部处理动态内容的能力。它使用外部处理器进行这种执行，并且将有一个等待期来向外部处理器发送请求并获得响应，这会显着降低性能。配置 Nginx 和外部处理器之间的通信有时也会变得复杂，尤其是当应用程序上有太多 Web 流量时。这在某种程度上是变相的好处。这使 Nginx 能够在内部以更快的速度处理静态内容。

结论： 由于网站的大部分内容都具有静态内容，并且大多数媒体文件实际上是 Web 应用程序的静态内容，因此人们总是发现 Nginx 提供比 Apache 更高的速度。这就是为什么多年来，如此多的网站所有者已经从 Apache + PHP-FPM 切换到 Nginx + PHP-FPM 并在处理巨大流量的同时获得了更好的性能。但是，如果您的网站有更多动态内容，而 PHP 必须完成大部分工作，而不是像静态内容网站那样 Web 服务器必须完成更多工作，那么 Apache 将始终提供更快的性能。

Answer 2

其实我试过Nginx + PHP+fpm，性能下降了一点。所以我将回到 Apache+PHP-fpm 并让 Nginx 为 Apache 做平衡器。我也使用 Nginx 来提供图片等静态内容。这是一个非常好的组合：Apache+PHP-fmp，Nginx 作为负载均衡器和静态内容服务器！

Answer 3

尽管有很多声称它更快，或者应该更快，但不，它不应该更快，至少不是无条件的。

究竟哪个更快，mod_php 或 ext-fpm，尚未得到证实，并且可能会有所不同。关于性能，您需要考虑三个方面：理论、实现、用例、资源和负载。

理论上，mod_php 是最快的。使用 mod_php，Web 服务器和解释器直接通信，它们共享相同的资源和内存空间。使用 ext-fpm，您有独立的进程，它们之间的通信不那么直接，而且必须复制资源。

传统上独立的进程很受欢迎，因为它们在诸如运行多个不同用户、同时运行不同版本等方面往往具有更大的灵活性。许多人还使用多个进程系统，因为他们不会被@987654321 打扰@、fclose()等

虽然 ext-fpm 使用 FastCGI 试图使分离进程模型达到其最大理论速度，但最大理论速度仍然低于统一进程的最大理论速度。

找出哪个最快可能很困难。即使精心编排，其他人的测试也不可靠，因为它们可能与您的用例和设置无关。在您自己的测试中，您可能会比另一个更快，但这并不意味着有人不能出现并改变它。有人可能是您，有更多的时间和理解供您使用。

mod_php 的实现不一定能达到其最大理论速度。两者可能没有人们预期的那么远，尤其是与服务静态请求时发生的其他所有事情相比，SAPI 开销通常是微不足道的。许多基准测试都必须使用几乎 noop 脚本进行测试，以使差异显得显着。

ext-fpm“很快”已成为一种流行的信念。有许多力量在坚持这一点，其中一些是无辜的，另一些来自无能，还有一些完全是操纵性的。

1. Apache httpd 不推荐使用 mod_php 由于各种原因，它不适用于线程 MPM。具有线程或事件驱动模型的 Apache httpd 可能会对不服务 PHP 的请求产生一些性能影响。虽然 PHP 在支持线程和事件驱动模型方面取得了重大进展，但对于事件驱动来说还有很长的路要走，而且它的线程支持还没有像传统的每个进程支持那样经过实战测试。许多人对此感到困惑。这不是让 PHP 更快的东西。这是一个权衡。潜在地减慢 PHP，加速静态内容。 Apache 已经开始完全反对 mod_php，这可能会让很多人感到困惑，并且可能的原因是错误地认为 ext-fpm “更快”。
2. 受到 Apache 推荐等因素的排斥，许多人尝试了 ext-fpm，然后使用他们的平台（如在会议或博客上的演讲）报告他们的轶事“成功”，然后将这种现象传播给更广泛的易受影响的受众。
3. 有时切换到 ext-fpm 效果会更好，但原因往往不是人们所期望的。许多人在从 mod_php 切换到 ext-fpm 时做得更多，或者其他因素在起作用。
4. 在技术领域，“快”这个词尤其成问题。它通常并不意味着什么。我使用的最后几个系统被称为快速（非常流行的技术），结果却恰恰相反。许多人将快速误认为是最快的意思。实际上，它往往没有多大意义。在感知方面快吗？对于大多数人来说，以 100 RPM 旋转的硬盘驱动器似乎“快速”旋转。对于大多数人来说，以 1000 RPM 旋转的硬盘驱动器似乎“快速”旋转。最快往往没有多大意义。
5. 利益冲突。 nginx 有一个商业项目，这是否可能成为 ext-fpm 营销的来源还有待观察。它为 nginx 服务，让人们相信它比 mod_php 更快，mod_php 仅适用于竞争的网络服务器。然而，有一个可用于 nginx 和 PHP 的线程派对模块，因此它似乎不太可能成为 ext-fpm 的游说来源。然而，谷歌的最高结果来自一个营销博客，该博客试图为商业托管服务带来流量，该服务跳过了大部分相关细节，因此显然有人在榨取它。

通常当人们看到不同的结果时，他们无法理解原因。他们的流程、测量和流量的私密细节被忽略了。然后人们经常尝试重复这些成功并失败，留下无尽的搜索结果，人们问为什么它不更快。最重要的是，人们在使用基于多进程的 MPM 和 mod_php 并同时承受大量静态内容负载时取得了成功。这些情况尤其具有欺骗性，因为静态请求的负载会反弹到 PHP 上。

另一个常见的错误是人们同时测试两种不同的配置。 php-fpm 的配置可能比 mod_php 的配置更优化。有时它可以像人们优化他们期望更快的所有内容一样简单，而忽略原始内容。这在人们可能会做一些事情时尤其相关，例如不检查请求是否成功，同时还更改诸如内存限制或最大执行时间之类的事情。当人们只打算更改 SAPI 时，配置中的很多事情都会发生变化，有时甚至是不可避免的，有时甚至是透明的。一个常见的例子可能是网络服务器的限制可能不足以最大限度地利用服务器的资源，而 ext-fpm 将能够产生额外的进程来利用额外的核心。人们经常看到人们将诸如路由从 PHP 转移到 FPM 的网络服务器之类的东西。

与具有多进程单线程 MPM 的 mod_php 相比，ext-fpm 是一个很好的竞争者，具有很多全面的好处，尽管不能严格保证更高的性能。尽管如果您的负载完全是为 PHP 请求提供服务，那么 Apache 已经在做 ext-fpm 本来会做的事情。

延迟与吞吐量以及周期与字节与等待之间也存在差异。

理论上，前进的道路是使用 ngx_php 或 mod_php 的 php-zts。最大的警告是，php-zts 并没有像 php-nts 那样得到几乎所有的关注和关注，因此它给 PHP 执行本身带来了开销，这使得目前很难与 php-fpm 竞争。实施并没有将其带入达到最佳状态的领域。在某些情况下，次优可能是轻描淡写的。许多人担心线程 PHP 的可靠性，这可能会或可能不会影响您。如果您只提供动态内容而不运行共享托管服务，这当然不会引起太大的关注。这似乎是 Apache 精心策划的一场恐惧运动。应该有足够多的人将 php-zts 用于平台，它是相对稳定的唯一选择。

还有其他选择，尽管它们可能需要更多的动手能力。甚至可以自己打开一个 unix 套接字，解析 FCGI 并使用诸如 select 之类的东西异步处理它。 PHP 中事件驱动的警告是，大多数主要的高级 IO 库（如 MySQL）并不以统一的方式支持它。

php-swoole 开始看起来很有希望，尽管它还处于早期阶段。 php-fpm、mod_php 和 php-zts 的情况一团糟。

Answer 4

我有一个运行 3 台服务器负载平衡的网站。其中 2 个在带有 PHP-FPM（新的）的 nginx 上运行。然而，主服务器在 Apache + PHP FastCGI 上，大约 40% 的流量。最近想把 Apache 也换成 nginx；所以我在同一台服务器上为不同的 IP 安装了 nginx 并做了一些测试。但令人惊讶的是，Apache 每次点击可以在 10-20 毫秒内生成页面，而 nginx 需要 60-70 毫秒。 nginx 处理静态文件速度更快，但如果你有 CDN，则无需担心静态内容。 Apache 是一个很棒的服务器。但是试试 FastCGI 而不是 PHP 模块。

Answer 5

我对此进行了更多研究，发现 Nginx 可以很好地处理静态资源，而不是其他动态内容交付，例如需要借助 php-fpm 等外部应用程序完成的 php 处理。因此，如果您的 Web 应用程序在 php 处理方面存在性能瓶颈，那么用 Nginx 替换 Apache 将不是一个解决方案。

下面的文章解释了使用 Apache + mod_php 和 Nginx + php-fpm 比较静态竞争交付和 php 脚本结果交付所做的详细研究。

http://blog.a2o.si/2009/06/24/apache-mod_php-compared-to-nginx-php-fpm/

以下是上述文章中描述的结论点。

结论或“你应该从 Apache 切换到 Nginx 吗？”

• 简短回答：我不知道。

• 更长的答案在这里：

  1. 如果您托管许多网站并且用户使用 .htaccess 文件并经常更改它们，那么答案可能是“否”。切换到 Nginx 并将所有配置转换为新格式的成本通常会达到购买另一台服务器的成本。
  2. 如果您在多台服务器上有一个应用程序，并且大部分处理能力没有被提供静态文件内容所消耗，那么答案也可能是“否”。
  3. 如果您主要提供静态内容，答案显然是“是”。
  4. 如果您正在为虚拟主机解决方案创建一个新系统，答案可能是“是”，假设用户不会错过 .htaccess 功能或将通过其他方式提供该功能
  5. 如果您使用某些虚拟化技术整合服务，那么答案可能是“是”，因为 Nginx 的内存占用往往比 Apache 小。
  6. 如果您希望将 Nginx 作为您的 PHP 服务器优化，请再看一遍，而不是 Nginx，而是您的应用程序代码。