是否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 version - 5.4.38;

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

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

访问登录页面

提交登录页面

访问主页

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

Nginx的性能略有提升，但是将所有服务器架构从Apache更改为Nginx并不是一个重大差异。当我观察服务器资源利用率时，我也没有发现Nginx和Apache之间存在很大差异

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

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

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

以下是我的问题。

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

Answer 1

我对此做了一些研究，发现Nginx在静态资源方面表现不错，而不是与其他动态内容交付相关，例如php处理需要在外部应用程序（如php-fpm）的帮助下完成。因此，如果您的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上查看您的应用程序代码。

Answer 2

我的网站运行时负载均衡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 3

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

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

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

传统上独立的流程之所以受欢迎，是因为它们在诸如运行多个不同用户，同时运行不同版本等方面具有更大的灵活性。许多人还使用多个流程系统，因为它们不会被{{ 1}}，free()等

虽然使用FastCGI的ext-fpm是使单独的过程模型满足其最大理论速度的尝试，但最大理论速度仍然比统一过程的最大理论速度慢。

找出最快的可能很困难。即使精心设计，其他人的测试也将不可靠，因为它们可能与您的用例和设置无关。在您自己的测试中，您可能比其他人做得更快，但这并不意味着某人无法改变。有人可能会成为您，让您有更多的时间和更多的理解力。

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，然后使用其平台（例如在会议或博客上的演讲）报告他们的轶事“成功”，然后将这一现象传播给更广为人知的受众。 / li>
3. 有时候将结果更好地转换为ext-fpm时，原因通常不是人们期望的。从mod_php切换到ext-fpm时，许多人所做的不止这些，否则其他因素也会发挥作用。
4. 在技术上，快速一词特别有问题。它通常并不真正意味着什么。我使用的最后几个被称为快速（非常流行的技术）的系统却相反。许多人很快就误解为最快的意思。实际上，它往往意义不大。快速感知？对于大多数人来说，以100RPM旋转的硬盘驱动器似乎正在“快速”旋转。对于大多数人来说，转速为1000RPM的硬盘驱动器似乎正在“快速”旋转。最快往往没有什么意义。
5. 利益冲突。 nginx有商业冒险，是否有可能成为ext-fpm的一些营销来源尚待观察。它为Nginx服务，使人们相信它比仅适用于竞争Web服务器的mod_php更快。但是，有一个可用于nginx和PHP的线程聚会模块，因此它似乎不太可能成为ext-fpm的源游说活动。但是，Google的最佳结果是来自一个营销博客，该博客试图将流量引入商业托管服务，从而跳过了大多数相关细节，因此有各方显然在挤奶它。

当人们看到不同的结果时，他们常常不明白为什么。他们的过程，测量和流量的内在细节被忽略了。然后，人们常常试图重复这些成功而失败，留下无休止的搜索结果，询问为什么它不那么快。最大的问题是，人们在将具有多内容的MPM与mod_php一起使用时发现成功，同时又承受了静态内容的沉重负担。由于静态请求的负载会反弹回PHP，因此这些情况尤其具有欺骗性。

另一个常见的错误是人们还要测试两种不同的配置。 php-fpm的配置可能比mod_php的配置更优化。有时候，就像人们在忽略原件的同时优化他们期望更快的所有东西一样简单。这在人们可能要做的事情（例如，不检查请求是否成功，同时还更改诸如内存限制或最大执行时间）之类的事情中尤其重要。当人们仅打算更改SAPI时，很多事情可能会更改配置，有时甚至是不可避免的，有时甚至是透明的。一个常见的示例可能是Web服务器上的限制可能不足以最大程度地利用服务器资源，而ext-fpm则将能够产生其他进程以利用其他核心。常见的是人们将诸如PHP之类的路由从PHP迁移到Web服务器以进行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

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

Answer 5

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

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

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