虽然有很多声称它更快的说法，但实际上并非如此，至少不是无条件地更快。
到底哪个更快，mod_php 还是 ext-fpm，还没有得到证明，而且可能会有所不同。在性能方面，您需要考虑三个因素：理论、实现、用例、资源和负载。
从理论上讲，mod_php 是最快的可达成的。使用 mod_php，Web 服务器和解释器直接通信，共享相同的资源和内存空间。而 ext-fpm 则需要通过分离的进程进行通信，并且必须复制资源。
传统上，独立的进程非常流行，因为它们通常具有更大的灵活性，例如可以作为许多不同用户、不同版本同时运行等。许多人也使用多进程系统，因为他们不想费心去 free()，fclose() 等操作。
虽然 ext-fpm 使用 FastCGI 尝试使分离进程模型达到其最大理论速度，但最大理论速度仍比统一进程的最大理论速度慢。
找出哪个更快可能是困难的。即使其他人的测试已经很好地组织，但它们可能与您的用例和设置无关，因此不可靠。在您自己的测试中，您可能会使其中一个比另一个更快，但这并不意味着其他人不能改变这一点。那个人可以是您，如果您有更多的时间和理解。
mod_php 的实现并不一定使它达到最大理论速度。两者之间的距离可能没有人们期望的那么远，特别是当很多时候 SAPI 开销与提供静态请求时发生的其他所有操作相比微不足道时。许多基准测试必须使用虚拟的 noop 脚本进行测试，以便差异显得明显。
已经成为普遍信仰的是 ext-fpm “很快”。许多力量维持了这种说法，其中一些是无辜的，另一些则源于无能，还有一些是纯粹的操纵。
- Apache httpd不建议使用mod_php与线程MPMs一起使用，有多种原因。带有线程或事件驱动模型的Apache httpd可能会对不提供PHP服务的请求产生一些性能影响。虽然PHP在支持线程和事件驱动模型方面取得了重大进展，但距离事件驱动仍有很长的路要走，而它的线程支持也没有像传统的进程支持那样经过充分的测试。许多人对此感到困惑。这并不是使PHP更快的东西，而是一种权衡。这可能会减慢PHP，加快静态内容。Apache已经开始完全不推荐使用mod_php，这可能会让很多人感到困惑，也可能是错误认为ext-fpm“更快”的产生的根源。
- 由于像Apache这样的推荐，许多人尝试了ext-fpm，然后在他们的平台上，如演讲或博客，报告了他们的轶事“成功”，这就将现象传播到更广泛的易受影响的观众中去。
- 有时候当切换到ext-fpm时，结果更好的原因往往不是人们所期望的。许多人从mod_php切换到ext-fpm时，会做更多的改变或其他因素会起作用。
- 在技术领域，快这个词尤其棘手。它经常并不真正意味着什么。我使用的几个品牌为快（非常流行的技术）的系统最后都被证明是相反的。许多人把快当成最快的意思。实际上，它往往意味着不多。在感知方面，快是什么？一个以100RPM旋转的硬盘对大多数人来说似乎在“快速”旋转。一个以1000RPM旋转的硬盘对大多数人来说似乎在“快速”旋转。最快往往意味着不多。
- 利益冲突。nginx有一个商业企业，尚不清楚它是否可能成为ext-fpm营销的来源。它为人们服务于nginx，使人们相信它比可供竞争web服务器使用的mod_php更快。然而，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应该做的事情。
还有一些差异，例如延迟与吞吐量、周期与字节与等待。
理论上，未来的方向是使用ngx_php或mod_php的php-zts。但是，重要的是要注意，与php-nts相比，php-zts没有得到足够的采用和关注，因此它会给PHP执行本身带来开销，这使得目前很难与php-fpm竞争。实现没有将其带入达到最佳状态的领域。在某些情况下，不太理想可能是一个低估的说法。许多人担心线程化的PHP可靠性问题，这可能会影响您，也可能不会。如果您只提供动态内容而不运行共享托管服务，则这肯定不会成为太大的问题。这似乎潜在地是由Apache组织的一场恐慌活动。有足够的使用php-zts的人在其中它是唯一选项的平台上，使它相对稳定。
还有其他选项，但可能需要更多的操作。甚至可以自己打开unix套接字，解析FCGI并使用诸如select之类的内容异步处理它。 PHP中基于事件驱动的缺点是，大多数主要的高级IO库（如MySQL）不以统一的方式支持它。
php-swoole看起来很有前途，尽管现在还为时过早。php-fpm、mod_php和php-zts的情况有些混乱。
mod_php中，它在同一进程内存空间中。 - zerkms