若转载教程，请注明出自SW-X框架官方文档
我们在PHP日常开发中听到最多的一个词可能就是PHP-FPM了。
但还是会有很多只用PHP，却不懂PHP的同行不知道PHP-FPM到底是什么东西？
在学习Swoole之前，我们必须了解PHP-FPM是干啥的，他主要做些什么工作。
前文我们有说过，FastCGI是基于CGI的多进程加强版，但在实际运行中，还依然面临很多问题，例如：
进程池的管理线程的分发PHP扩展的加载方式，这部分内存如何缓存常驻调用PHP-SAPI新增的代码如何解析加载修改了PHP.ini如何热更新
等这一系列的问题都等着FastCGI来实现，但FastCGI只是PHP的运行模式之一，按分层概念来说，它不应该负责这些工作，它的工作只是给我们定义了实现的可能性与实现规范。
而PHP-FPM就是根据这些规范在FastCGI之上再封装的一层请求处理机制。

1、mod_php模式

下面我们先来看看第一版原始的请求处理机制，这个机制就是起初PHP火不起来的原因之一：
mod_php 模式是将php模块安装到apache中，所以每一次apache结束的请求呢，都会产生一条进程，这个进程就完整的包括php的各种运算计算等操作。
image.png
从图中我们很清晰的可以看到，apache每接收一个请求，都会产生一个进程来连接php通过sapi来完成请求，可想而知，如果一旦用户过多，并发数过多，服务器就会承受不住了。
而且，把mod_php编进apache时，出问题时很难定位是php的问题还是apache的问题。

2、mod_fastcgi模式

实际上再PHP-FPM还没面世之前，官方根据FastCGI提供了一个名为mod_fastcgi的请求处理机制。
mod_fastcgi模式则跟mod_php模式刚刚相反，fastcgi是一个独立与apache和php的独立个体，它随着apache一起启动，生成多个cig模块，等着apache的请求：
image.png
图中fastcgi早早的启动好了，静静的在哪里等着，已有apache发来的httpd请求就立马接收过来，通过调用sapi给php，完成运算。
而且不会退出。
这样就能应对大规模的并发请求，因为web server的要做的事情少了，所以就更快的去处理下一个请求，这样并发能力大大提升。
由于apache 与 php 独立了，出问题可以更好定位到底是哪里出问题。这点也是这种模式受欢迎的原因之一。

3、php-fpm模式

我们直接开门见山先说PHP-FPM到底是干嘛的。
其实，它就是专门用来辅助mode_fastcgi模式的。
嗯。很好，先知道它是干嘛的了，然后，我们再回到mode_fastcgi模式。
通过前面的瞎鸡巴一大堆的说明，我已经搞清楚了这种模式是怎么样子的一种状态了。
FastCGI是一个与平台无关，与语言无关，任何语言只要按照它的接口来实现，就能实现自己的代码通过FastCGI和web server进行通讯。
PHP-CGI就是PHP实现的自带的FastCGI管理器。
虽然是php官方出品，自带的，但是这丫的却一点也不给力，性能太差，而且也很麻烦不人性化，主要体现在：
php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效，不可以平滑重启。
直接杀死php-cgi进程，php就不能运行了。
上面2个问题，一直让很多人病垢了很久，所以很多人一直还是在用mode_php方式。
直到 2004年(确定是这么早吗？)一个叫 Andrei Nigmatulin的屌丝发明了PHP-FPM ，这神器的出现就彻底打破了这种局面，这是一个PHP专用的FastCGI管理器，它很爽的克服了上面2个问题，而且，还表现在其他方面更表现强劲。

4、为什么学习Swoole，我们需要了解PHP的运行模式

Swoole是一款基于C语言编写的多进程PHP扩展，它可以通过CLI模式调用Zend引擎解析代码进而运行PHP代码，这种模式下我们已经有可能性实现脱离PHP-FPM管理器，自己定义一个多进程的HTTP处理机制了，然后再把处理端口指向Apache或Nginx。
真正的PHP高手已经是不再依赖PHP-FPM运行，毕竟自己掌控进程，线程后可以做更多的事情，而且通过之前的文章我们已经理解到，Swoole的进程模式比FastCGI的进程模式要好很多的，最主要能掌握在开发者自己手上。