我对此做了更多的研究，发现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.更长的答案在这里：
1.如果您托管许多网站和用户使用。htaccess文件并频繁更改它们，那么答案可能是“不”。切换到Nginx并将所有配置转换为新格式的成本通常达到购买另一台服务器的成本。
1.如果您在多个服务器上有一个应用程序，并且大部分处理能力并不用于提供静态文件内容，那么答案也可能是“否”。
1.如果你主要服务于静态内容，答案显然是“是”。
1.如果您正在创建一个新的系统的虚拟主机解决方案，答案可能是“是”，假设用户不会错过。htaccess功能，或者它将通过其他方式提供
1.如果您正在使用一些虚拟化技术整合服务，那么答案可能是“是”，因为Nginx往往比Apache占用更小的内存。
1.如果你正在寻找Nginx作为你的PHP服务器优化，再看看你的应用程序代码，但不是Nginx。

尽管有很多人声称它更快，或者应该更快，不，它不应该更快，至少不是无条件的。
究竟哪个更快，mod_php还是ext-fpm，还没有被证明，它可能会有所不同。关于性能，您有三个考虑因素：理论、实现、用例、资源和负载。
理论上，mod_php是最快的。使用mod_php，Web服务器和解释器直接通信，它们共享相同的资源和内存空间。使用ext-fpm，您有单独的进程，这些进程之间的通信不直接，并且必须复制资源。
传统上，独立的进程很受欢迎，因为它们在诸如同时运行许多不同的用户、不同的版本等方面往往具有更大的灵活性。许多人还使用多个进程系统，因为他们不想麻烦free()，fclose()等。
虽然使用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“更快”的原因。
   1.由于受到Apache推荐等因素的影响，许多人尝试了ext-fpm，然后利用他们的平台，如在会议或博客上的演讲，报告他们的轶事“成功”，然后将这种现象传播给更广泛的易受影响的受众。
   1.有时候，当切换到ext-fpm的结果更好时，原因往往不是人们所期望的。许多人在从mod_php切换到ext-fpm时，做的不仅仅是这些，或者是其他因素在起作用。
   1.在技术领域，“快”这个词尤其成问题。它通常并不意味着什么。我使用的最后几个系统被贴上了快速（非常流行的技术）的标签，结果却恰恰相反。很多人误以为“快”就是“最快”。实际上，这并不意味着什么。在感知方面，快？对于大多数人来说，以100 RPM转速旋转的硬盘似乎“快”。在大多数人看来，以1000 RPM旋转的硬盘似乎旋转得“快”。最快并不意味着什么。
   1.利益冲突。nginx有一个商业风险，这是否可能成为ext-fpm的一些营销来源还有待观察。它为nginx服务，让人们相信它比mod_php更快，后者只适用于竞争对手的web服务器。然而，有一个线程党模块可用于nginx和PHP，所以它看起来不像是一个可能的来源游说ext-fpm。然而，谷歌的最高结果来自一个营销博客，该博客试图为商业托管服务带来流量，但跳过了大部分相关细节，因此各方显然从中获利。

通常当人们看到不同的结果时，他们无法理解为什么。他们的过程、测量和交通的细节都被遗漏了。然后人们经常尝试重复这些成功和失败，留下无休止的搜索结果的人问为什么它不是更快。最大的一个是人们在使用基于多进程的MPM和mod_php时发现成功，同时具有静态内容重负载。这些情况特别具有欺骗性，因为静态请求的负载可能会反弹回PHP。
另一个常见的错误是人们还测试了两种不同的配置。php-fpm的配置可能比mod_php的配置更优化。有时候，它可以像人们优化他们期望更快的东西一样简单，而忽略了原来的东西。这在人们可能做诸如不检查请求是否成功之类的事情，同时还改变诸如内存限制或最大执行时间之类的事情时尤其相关。当人们只打算更改SAPI时，配置中的许多事情可能会发生变化，有时甚至是不可避免的，有时甚至是透明的。一个常见的例子可能是web服务器上的限制可能不足以最大化服务器资源的利用率，而ext-fpm将能够产生额外的进程以利用额外的核心。人们经常会看到一些事情，比如从PHP路由到FPM的Web服务器。
与带有多进程单线程MPM的mod_php相比，ext-fpm是一个很好的竞争者，具有很多全面的好处，尽管不能严格保证更高的性能。但是如果你的负载完全是为PHP请求服务的，那么Apache已经做了ext-fpm本来会做的事情。
在延迟与吞吐量、周期与字节与等待等方面也存在差异。
从理论上讲，前进的道路是php-zts与ngx_php或mod_php。最大的警告是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的情况是一团糟。

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

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

Apache使用传统的基于文件的方法来处理静态内容。这种传统的方法有点过时，这就是为什么它的性能稍低，如果你考虑到今天处理静态内容的高标准。另一方面，Apache Web服务器更重视动态内容，并通过嵌入式处理器处理它们。动态内容通过Web服务器执行，不需要外部组件。
正是这种在内部处理动态内容的能力使Apache成为具有更多动态内容的Web应用程序的最佳Web服务器。来到Nginx，Nginx缺乏在内部处理动态内容的能力。它使用外部处理器进行这种执行，并且将有一段等待时间用于向外部处理器发送请求并获得响应，这会显着降低性能。配置Nginx和外部处理器之间的通信有时也会变得复杂，特别是当应用程序上有太多Web流量时。这在某种程度上是一种变相的好处。这使得Nginx能够在内部以更快的速度处理静态内容。

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

为了支持Thilanka的发现，在过去的15年多里，我在我认为高流量的环境中管理服务器，当人们活跃时，平均每秒有66个动态页面，而不是点击，每个服务器的页面。对于那些纸上谈兵的Maven来说，这似乎不算什么，但请记住，这些是动态页面，我们必须从世界各地的来源获取信息，这需要时间，也需要广告。此外，还可以动态生成Map，其中填充了数据，使当前条件和预测数据读起来像天气预报员说的那样。你可以缓存你能缓存的，只要它保持最新，但是源的响应时间也会变化，有时它们不能按时交付，你需要切换到备用的和更昂贵的源，一小时中的某些时间你需要删除和重新加载数据库中的151，000行，所有这些都会影响请求所需的时间，这决定了你有多少活动连接。当世界上某些地方天气不好时，交通量可能会增加一倍，导致观看性能图表时出现一些紧张时期。然后还有攻击者根据您的设置调整攻击，并切断那些试图免费使用服务器获取内容的人。速度影响页面排名，谷歌说页面很快。我不认为自己是这方面的Maven，但我可以告诉你，在喝了NGINX（和其他人）的Kool-Aid之后，甚至使用NGINX作为Apache的反向代理，我都无法复制许多人所吹嘘的结果。我总是以更慢，或者不一致的性能，或者不稳定而告终，通常是其中两种的组合。当我问其他人谈论他们的收益时，他们要么没有负担，谈论在线基准，甚至可能使用过它们，而且主要是基于感觉。NGINX在某些场景中必须很好，因为大型站点使用它。然而，我不能不相信，在许多情况下，基准测试和炒作驱使NGINX在实际上是不利的地方实现。在竞争激烈的共享主机环境中，他们需要在每台服务器上获得尽可能多的用户。他们通常默认为Apache，但如果这对他们来说是一个重大的惩罚，他们可能不会。我说这一切是为了说，虽然NGINX很可能在某些流量组合中具有优势，但很有可能你会发现这些收益在你的环境中是难以捉摸的。即使它会稍微快一点，但无可争辩的是Apache更稳定，更灵活，有更多插件，更全面，更好地验证，更容易实现，更安全，而且Apache对开发人员更友好。然而，我对新的想法持开放态度，我的探索把我带到了这里。只是我的两分钱。