假设 Nginx + php-fpm 比 Apache + mod-php 快得多

Is Nginx + php-fpm is suppose be much faster than Apache + mod-php

提问by Thilanka

I'm having a PHP based web application running on Apache server which has considerable amount of php processing in back end. Since the overall performance is low I worked on improving the performance of the application. First I followed techniques such as client side caching, gzip enabling, js-css minifying which improved the performance upto a good extend.

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

In order to further improve the performance I wanted to try out server level improvement. So I tried to compare the application performance by hosting it on Apache and Nginx servers.

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

• Nginx version - 1.0.15;
• Apache version - 2.2.15;
• php version - 5.4.38;

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

In Apache I user Apache + mod-php and in Nginx I used Nginx + php-fpm for this comparison. As most of the tutorials explained I configured the number of Nginx workers equal to the number of cores in my processor. I used jmeter to do the stress testing and following are the graphs I could generate out of it.

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

In all these graphs x-axis is each request I sent and y-axis is milliseconds for getting response for each request.

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

Access the login page

访问登录页面

Submit the login page

提交登录页面

Access home page

访问主页

I could only perform the testing upto 100 concurrent users logged in within 1 second because it started dropping requests after then in both server setups.

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

There was a little improvement on performance in Nginx than Apache but it was not a major difference where it's worth to change all my server architecture from Apache to Nginx. And when I observe the server resource utilization also I didn't find much of difference between Nginx and Apache

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

When I went through other comparisons people have done, I found that they claim Nginx is much more faster in concurrent accesses such as following graph shows.

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

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

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

But I was unable to observe any major difference of performance in Nginx over Apache even with 100 concurrent access within 1 second.

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

Following are my questions.

以下是我的问题。

1. Is Nginx + php-fpm is suppose to do server operations much faster than Apache + mod-php due to efficient usage of memory and other resources ?
2. Is Nginx only recommended to server static contend and not for heavy server operation sites ?
3. Is there any better way of configuring Nginx to gain more performance improvement ?

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

回答by Thilanka

I did a bit more research on this and found that Nginx will perform well with static resources and not with other dynamic content delivery such as php processing which needs to done with the help of external application such as php-fpm. So if your web application has a performance bottleneck on php processing then replacing Apache with Nginx will not be a solution.

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

Following article explains a details research done on comparing static contend delivery and php script result delivery using Apache + mod_php and Nginx + php-fpm.

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

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

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

Following are the conclusion points described in the above article.

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

Conclusion or “should you switch from Apache to Nginx?”

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

• Short answer: I do not know.

• Longer answers are here:

  1. If you host many websites and users utilize .htaccess files and change them frequently, then the answer is probably “no”. The cost of switching over to Nginx and converting all the configuration to new format usually reaches the cost of buying another server.
  2. If you have single application on multiple servers and most of the processing power is not consumed by serving static file content, the answer is also probably “no”.
  3. If you are mainly serving static content, the answer is obviously “yes”.
  4. If you are creating a fresh system for webhosting solution, the answer is probably “yes”, with the assumption that users will not miss the .htaccess functionality or it will be provided by other means
  5. If you are consolidating services with some virtualization technology, then answer is probably “yes”, as Nginx tends to have smaller memory footprint than Apache.
  6. If you are looking towards Nginx as your PHP server optimization, look again, but not at Nginx, at your application code.

• 简短的回答：我不知道。

• 更长的答案在这里：

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

回答by jgmjgm

Despite there being a lot of claims that it's faster, or supposed to be, no, it's not supposed to be faster, at least not unconditionally.

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

Exactly which is faster, mod_php or ext-fpm, hasn't been proven and it's likely to vary. In respect to performance you have three considerations, theory, implementation, use case, resources and load.

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

In theory, mod_php is the fastest achievable. With mod_php the web server and interpreter directly communicate, they share the same resources and memory space. With ext-fpm you have separate processes that communicate not as directly and that must duplicate resources.

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

Traditionally separate processes are popular because they tend to have greater flexibility in respect to things such as running as many different users, different versions concurrently, etc. Many people also use multiple process systems as they can't be bothered to free(), fclose(), etc.

传统上独立的过程很受欢迎，因为他们往往有有关的东西了更大的灵活性，如同时运行许多不同的用户，不同的版本，等等。许多人还使用多进程系统，因为他们不能打扰到free()，fclose()等等。

While ext-fpm, using FastCGI, is an attempt to make the separate process model meet its maximum theoretical speed, the maximum theoretical speed is still slower than the maximum theoretical speed of unified processes.

而ext-fpm，使用FastCGI，是为了使分离进程模型达到其最大理论速度的尝试，但最大理论速度仍然比统一进程的最大理论速度慢。

Finding out which is fastest can be difficult. Other people's tests wont be reliable even if well orchestrated as they may not be relevant to your use case and your setup. In your own tests you may make one faster than the other but it doesn't mean someone can't come along and change that. That someone could be you with more time and understanding at your disposal.

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

The implementation of mod_php isn't necessarily one that brings it to its maximum theoretical speed. The two might not be as far apart as people might expect especially as quite often the SAPI overhead can turn out to be trivial in comparison to everything else that goes on when serving a static request. Many benchmarks are having to test with virtually noop scripts so that the difference appears significant.

mod_php 的实现不一定会使其达到最大理论速度。这两者可能没有人们预期的那么远，特别是因为与处理静态请求时发生的其他所有事情相比，SAPI 开销经常被证明是微不足道的。许多基准测试必须使用几乎 noop 脚本进行测试，因此差异似乎很重要。

It has become a popular belief that ext-fpm "is fast". There are many forces which persist this, some of which are innocent, others draw from incompetence and some are down right manipulative.

人们普遍认为 ext-fpm “很快”。有许多力量坚持这一点，其中一些是无辜的，另一些来自无能，而另一些则是操纵性的。

1. Apache httpd doesn't want to recommend using mod_php doesn't work with threaded MPMs for various reasons. Apache httpd with threaded or event driven models which can have some performance impact requests that aren't serving PHP. While PHP has made significant progress towards supporting both threaded and event driven models, it's still a long way off for event driven and it's threaded support haven't been quite as battle tested as it's traditional per process support. Many people are confused by this. It's not something that makes PHP faster. It's a trade off. Potentially slow down PHP, speed up static content. Apache has started recommending against mod_php entirely which is likely to confuse a lot of people as well as the likely origin of the mistaken believe that ext-fpm "is faster".
2. Spurned by things such as the Apache recommendation, many people have tried ext-fpm and then used their platforms such as speeches at conferences or blogs to report their anecdotal "successes" which then propagates the phenomena to a wider impressionable audience.
3. Sometimes when results are better switching to ext-fpm, the reasons often aren't what people expect. Many people when switching from mod_php to ext-fpm are doing more than that or other factors are at play.
4. In technology the word fast is particularly problematic. It often doesn't really mean anything. The last several systems I've used which have been branded as fast (very popular technologies) have turned out to be the opposite. Many people mistake fast for meaning fastest. In reality it tends not to mean much. Fast in terms of perception? A harddrive spinning at 100RPM will appear to be spinning "fast" to most people. A harddrive spinning at 1000RPM will appear to be spinning "fast" to most people. Fastest tends not to mean much.
5. Conflicts of interest. nginx has a commercial venture and it remains to be seen if that might be a source of some marketing for ext-fpm. It serves nginx for people to believe that it's faster than mod_php which is only available for a competing webserver. There is however a thread party module available for nginx and PHP so it doesn't seem like it would be a likely source lobbying for ext-fpm. The top result in Google however is from a marketing blog trying to bring in traffic to commercial hosting services that skips most of the pertinent details so there are parties clearly milking it.

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 的可能来源游说。然而，谷歌的最高结果来自试图为商业托管服务带来流量的营销博客，该博客跳过了大部分相关细节，因此有各方显然在挤奶。

Often when people see a different result they fail to appreciate why. The intimate details of their process, measurements and traffic are left out. People then often attempt to repeat these successes and fail leaving endless search results of people asking why it's not faster. The big one is people finding success when using a multiple-process based MPM with mod_php while having a static content heavy load. These cases can be especially deceptive as the load from static requests can bounce back onto PHP.

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

Another common mistake is for people to also test two different configurations. The configuration for php-fpm might be more optimised than that for mod_php. Sometimes it can be as simple as people optimising everything about the one they expect to be faster while neglecting the original. This is especially relevant where people might do things such as not check whether requests were successful while also changing things such as the memory limit or maximum execution time. A lot of things can change in the configuration when people are only meant to change the SAPI, sometimes even unavoidably, sometimes even transparently. A common example might be that the limits on the webserver might be insufficient to maximise utilisation of the server's resources where as ext-fpm will be able to spawn additional processes to take advantage of additional cores. It's common to see people move things such as routing over from PHP to the webserver for FPM.

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

Compared to mod_php with a multiple-process-single-threaded MPM, ext-fpm is a good contender with a lot of all round benefits though greater performance isn't strictly guaranteed. Though if your load is entirely serving PHP requests then Apache is already more of less doing what ext-fpm would otherwise be doing.

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

There's also a discrepancy between things such as latency versus throughput and cycles versus bytes versus waits.

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

In theory, the way forward is php-zts with either ngx_php or mod_php. The big caveat is that php-zts hasn't gotten nearly the uptake nor care and attention as php-nts such that it introduces overhead to PHP execution itself which makes it very hard to compete with php-fpm at present. The implementation does not bring it into the realm of reaching its optimum. In some cases suboptimum might be an understatement. Many people are concerned about the reliability of threaded PHP which may or may not impact you. It certainly wont be as much of a concern if you're only serving dynamic content and not running a shared hosting service. This appear to potentially be a fear campaign orchestrated by Apache. There should be enough people using php-zts for platforms where it's the only option for it to be relatively stable.

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

There are other options though they may be more hands on. It's even possible to open a unix socket yourself, parse the FCGI and handle it asynchronously with things such as select. The caveat of event driven in PHP is that most of the major high level IO libraries such as MySQL don't support it in a unified fashion.

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

php-swoole is starting to look promising though it's early days yet. The situation with php-fpm, mod_php and php-zts is a mess.

php-swoole 虽然还处于早期阶段，但看起来很有希望。php-fpm、mod_php 和 php-zts 的情况是一团糟。

回答by Gichan

I have a website running with load balancing of 3 servers. 2 of them are running on nginx with PHP-FPM (new ones). However the main server is on Apache + PHP FastCGI hittng roughly 40% traffic. Recently I thought of changing Apache also to nginx; so I installed nginx on the same server for a different IP and did some tests. But surprisingly, Apache could generate the page in 10-20 milliseconds on each hit but nginx takes 60-70 milliseconds. nginx is faster for static files, but if you have a CDN there is no need to worry about static content. Apache is a great server. But try FastCGI and not the PHP module.

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