是否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 I用户Apache + mod-php和Nginx中,我使用Nginx + php-fpm进行比较.正如大多数教程所解释的那样,我将Nginx工作者的数量配置为等于处理器中的核心数量.我用jmeter做了压力测试,下面是我可以用它生成的图表.

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

访问登录页面

提交登录页面

访问主页

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

Nginx的性能比Apache有所改善,但是将我的所有服务器架构从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. 如果您正在为webhosting解决方案创建一个全新的系统,答案可能是"肯定",假设用户不会错过.htaccess功能,或者它将通过其他方式提供
  5. 如果您使用某些虚拟化技术整合服务,那么答案可能是"肯定",因为Nginx的内存占用量往往比Apache小.
  6. 如果您正在考虑将Nginx作为您的PHP服务器优化,请再次查看,但不要在Nginx上查看您的应用程序代码.

Answer 2

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

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

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

传统上独立的过程很受欢迎，因为他们往往有有关的东西了更大的灵活性，如同时运行许多不同的用户，不同的版本，等等。许多人还使用多进程系统，因为他们不能打扰到free()，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. 在技​​术中，快速这个词尤其成问题。它通常并不意味着什么。我使用的最后几个系统被标记为快速（非常流行的技术），结果却恰恰相反。许多人将快速误认为是最快的意思。实际上，它往往没有多大意义。感知速度快？对于大多数人来说，以 100RPM 旋转的硬盘驱动器似乎“快速”旋转。对于大多数人来说，以 1000RPM 旋转的硬盘驱动器似乎“快速”旋转。最快的往往意义不大。
5. 利益冲突。nginx 有一个商业风险，它是否可能成为 ext-fpm 的一些营销来源还有待观察。它为 nginx 服务，让人们相信它比 mod_php 更快，后者仅适用于竞争的网络服务器。然而，有一个线程派对模块可用于 nginx 和 PHP，所以它似乎不是 ext-fpm 游说的可能来源。然而，谷歌的最高结果来自试图为商业托管服务带来流量的营销博客，该博客跳过了大部分相关细节，因此有各方显然在挤奶。

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

另一个常见的错误是人们同时测试两种不同的配置。php-fpm 的配置可能比 mod_php 的配置更优化。有时它可以像人们优化他们期望更快的所有内容而忽略原始内容一样简单。这在人们可能会做一些事情时尤其重要，比如不检查请求是否成功，同时还改变了诸如内存限制或最大执行时间之类的事情。当人们只想更改 SAPI 时，配置中的很多事情都可以更改，有时甚至是不可避免的，有时甚至是透明的。一个常见的例子可能是网络服务器的限制可能不足以最大限度地利用服务器' s 资源，其中 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 3

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