CGI，FastCGI，PHP-CGI与PHP-FPM(转)

http://www.cnblogs.com/zl0372/articles/php_4.html

 

 

CGI

CGI全称是“公共网关接口”(Common Gateway Interface)，HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。

CGI自己能够当作是一种协议标准，它能够用任何一种语言编写具体的符合该接口标准的协议存在，只要这种语言具备标准输入、输出和环境变量。如php,perl,tcl等。

 

FastCGI

FastCGI像是一个常驻(long-live)型的CGI，它能够一直执行着，只要激活后，不会每次都要花费时间去fork一次（这是CGI最为人诟病的fork-and-execute 模式）。它还支持分布式的运算，即 FastCGI 程序能够在网站服务器之外的主机上执行而且接受来自其它网站服务器来的请求。

FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并所以得到较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要缘由，若是CGI解释器保持在内存中并接受FastCGI进程管理器调度，则能够提供良好的性能、伸缩性、Fail- Over特性等等。

FastCGI也能够称为是一种协议标准，好比下面要说的php-fpm就是支持解析php的一个fastCGI进程管理器/引擎。

 

 

 

FastCGI特色

1. FastCGI具备语言无关性.
2. FastCGI在进程中的应用程序，独立于核心web服务器运行，提供了一个比API更安全的环境。APIs把应用程序的代码与核心的web服务器连接在一块儿，这意味着在一个错误的API的应用程序可能会损坏其余应用程序或核心服务器。 恶意的API的应用程序代码甚至能够窃取另外一个应用程序或核心服务器的密钥。
3. FastCGI技术目前支持语言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相关模块在Apache, ISS, Lighttpd等流行的服务器上也是可用的。
4. FastCGI的不依赖于任何Web服务器的内部架构，所以即便服务器技术的变化, FastCGI依然稳定不变。

FastCGI的工做原理

1. Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)
2. FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的链接。
3. 当客户端请求到达Web Server时，FastCGI进程管理器选择并链接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
4. FastCGI子进程完成处理后将标准输出和错误信息从同一链接返回Web Server。当FastCGI子进程关闭链接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个链接。 在CGI模式中，php-cgi在此便退出了。

在上述状况中，你能够想象CGI一般有多慢。每个Web请求PHP都必须从新解析php.ini、从新载入所有扩展并重初始化所有数据结构。使用FastCGI，全部这些都只在进程启动时发生一次。一个额外的好处是，持续数据库链接(Persistent database connection)能够工做。

FastCGI的不足

由于是多进程，因此比CGI多线程消耗更多的服务器内存，PHP-CGI解释器每进程消耗7至25兆内存，将这个数字乘以50或100就是很大的内存数。

Nginx 0.8.46+PHP 5.2.14(FastCGI)服务器在3万并发链接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。若是服务器内存较小，彻底能够只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
上面的数据摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建赛过Apache十倍的Web服务器(第6版)

PHP-CGI

PHP-CGI是PHP自带的FastCGI管理器。

PHP-CGI的不足：

1. php-cgi变动php.ini配置后需重启php-cgi才能让新的php-ini生效，不能够平滑重启。
2. 直接杀死php-cgi进程，php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题，守护进程会平滑重新生成新的子进程。）

PHP-FPM

PHP-FPM是一个PHP FastCGI管理器，是只用于PHP的，能够在 http://php-fpm.org/download下载获得。

PHP-FPM实际上是PHP源代码的一个补丁，旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中，在编译安装PHP后才可使用。

如今咱们能够在最新的PHP 5.3.2的源码树里下载获得直接整合了PHP-FPM的分支，听说下个版本会融合进PHP的主分支去。相对Spawn-FCGI，PHP-FPM在CPU和内存方面的控制都更胜一筹，并且前者很容易崩溃，必须用crontab进行监控，而PHP-FPM则没有这种烦恼。

PHP5.3.3已经集成php-fpm了，再也不是第三方的包了。PHP-FPM提供了更好的PHP进程管理方式，能够有效控制内存和进程、能够平滑重载PHP配置，比spawn-fcgi具备更多有点，因此被PHP官方收录了。在./configure的时候带 –enable-fpm参数便可开启PHP-FPM。

Spawn-FCGI

Spawn-FCGI是一个通用的FastCGI管理服务器，它是lighttpd中的一部份，不少人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工做，不过有很多缺点。而PHP-FPM的出现多少缓解了一些问题，但PHP-FPM有个缺点就是要从新编译，这对于一些已经运行的环境可能有不小的风险(refer)，在php 5.3.3中能够直接使用PHP-FPM了。

Spawn-FCGI目前已经独成为一个项目，更加稳定一些，也给不少Web 站点的配置带来便利。已经有很多站点将它与nginx搭配来解决动态网页。

最新的lighttpd也没有包含这一块了(http://www.lighttpd.net/search?q=Spawn-FCGI)，但能够在之前版本中找到它。在lighttpd-1.4.15版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)，目前Spawn-FCGI的下载地址是http://redmine.lighttpd.net/projects/spawn-fcgi，最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz。

注：最新的Spawn-FCGI能够到lighttpd.net网站搜索“Spawn-FCGI”找到它的最新版本发布地址。

PHP-FPM与spawn-CGI对比

PHP-FPM的使用很是方便，配置都是在PHP-FPM.ini的文件内，而启动、重启均可以从php/sbin/PHP-FPM中进行。更方便的是修改php.ini后能够直接使用PHP-FPM reload进行加载，无需杀掉进程就能够完成php.ini的修改加载
结果显示使用PHP-FPM可使php有不小的性能提高。PHP-FPM控制的进程cpu回收的速度比较慢,内存分配的很均匀。
Spawn-FCGI控制的进程CPU降低的很快，而内存分配的比较不均匀。有不少进程彷佛未分配到，而另一些却占用很高。多是因为进程任务分配的不均匀致使的。而这也致使了整体响应速度的降低。而PHP-FPM合理的分配，致使整体响应的提到以及任务的平均。

总结：

　　 f astCGI是nginx和php之间的一个通讯接口，该接口实际处理过程经过启动php-fpm进程来解析php脚本，即 php-fpm至关于一个动态应用服务器，从而实现nginx动态解析php。所以，若是nginx服务器须要支持php解析，须要在nginx.conf中增长php的配置：将php脚本转发到fastCGI进程监听的IP地址和端口（php-fpm.conf中指定）。同时，php安装的时候，须要开启支持fastCGI选项，而且编译安装php-fpm补丁/扩展，同时，须要 启动php-fpm进程，才能够解析nginx经过fastCGI转发过来的php脚本。

 

 

 

php-fpm是一个彻底独立的程序,不依赖php-cgi,也不依赖php.由于php-fpm是一个内置了php解释器的FastCGI服务,启动时可以自行读取php.ini配置和php-fpm.conf配置.

附:PHP FastCGI进程管理器PHP-FPM的架构
一个master进程,支持多个pool,每一个pool由master进程监听不一样的端口,pool中有多个worker进程.
每一个worker进程都内置PHP解释器,而且进程常驻后台,支持prefork动态增长.
每一个worker进程支持在运行时编译脚本并在内存中缓存生成的opcode来提高性能.
每一个worker进程支持配置响应指定请求数后自动重启,master进程会重启挂掉的worker进程.
每一个worker进程能保持一个到MySQL/Memcached/Redis的持久链接,实现"链接池",避免重复创建链接,对程序透明.
master进程采用epoll模型异步接收和分发请求,listen监听端口,epoll_wait等待链接,
而后分发给对应pool里的worker进程,worker进程accpet请求后poll处理链接,
若是worker进程不够用,master进程会prefork更多进程,
若是prefork达到了pm.max_children上限,worker进程又全都繁忙,
这时master进程会把请求挂起到链接队列backlog里(默认值是511).

 

 

web server（好比说nginx）只是内容的分发者。好比，若是请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。好了，若是如今请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，须要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串也得有吧，POST数据也要有，HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。仔细想一想，你在PHP代码中使用的用户从哪里来的。

当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，而后处理请求，再以规定CGI规定的格式返回处理后的结果，退出进程。web server再把结果返回给浏览器。

     好了，CGI是个协议，跟进程什么的不要紧。那fastcgi又是什么呢？Fastcgi是用来提升CGI程序性能的。

提升性能，那么CGI程序的性能问题在哪呢？"PHP解析器会解析php.ini文件，初始化执行环境"，就是这里了。标准的CGI对每一个请求都会执行这些步骤（不闲累啊！启动进程很累的说！），因此处理每一个时间的时间会比较长。这明显不合理嘛！那么Fastcgi是怎么作的呢？首先，Fastcgi会先启一个master，解析配置文件，初始化执行环境，而后再启动多个worker。当请求过来时，master会传递给一个worker，而后当即能够接受下一个请求。这样就避免了重复的劳动，效率天然是高。并且当worker不够用时，master能够根据配置预先启动几个worker等着；固然空闲worker太多时，也会停掉一些，这样就提升了性能，也节约了资源。这就是fastcgi的对进程的管理。

    那PHP-FPM又是什么呢？是一个实现了Fastcgi的程序，被PHP官方收了。

你们都知道，PHP的解释器是php-cgi。php-cgi只是个CGI程序，他本身自己只能解析请求，返回结果，不会进程管理（皇上，臣妾真的作不到啊！）因此就出现了一些可以调度php-cgi进程的程序，好比说由lighthttpd分离出来的spawn-fcgi。好了PHP-FPM也是这么个东东，在长时间的发展后，逐渐获得了你们的承认（要知道，前几年你们但是抱怨PHP-FPM稳定性太差的），也愈来愈流行。

 

fastcgi是一个协议，php-fpm实现了这个协议

    

php-fpm的 管理对象 是php-cgi。但不能说php-fpm是fastcgi进程的管理器，由于前面说了fastcgi是个协议，

之前php-fpm没有包含在PHP内核里面，要使用这个功能，须要找到与源码版本相同的php-fpm对内核打补丁，而后再编译。

后来PHP内核集成了PHP-FPM以后就方便多了，使用--enalbe-fpm这个编译参数便可。

    有的说，修改了php.ini配置文件后，没办法 平滑重启，因此就诞生了php-fpm

是的，修改php.ini以后，php-cgi进程的确是没办法平滑重启的。php-fpm对此的处理机制是新的worker用新的配置，已经存在的worker处理完手上的活就能够歇着了，经过这种机制来平滑过分。

     还有的说PHP-CGI是PHP自带的FastCGI管理器，那这样的话干嘛又弄个php-fpm出

不对。php-cgi只是解释PHP脚本的程序而已。    

 

 

 

 

 

FastCGI像是一个常驻(long-live)型的CGI，是用来提升CGI程序性能的。CGI是通用网关接口，是外部应用程序与Web 服务器之间的接口标准，CGI是为了保证web server传递过来的数据是标准格式的，方便CGI程序的编写者。若是请求的是静态数据 /index.html，那么web server会去文件系统找到这个文件发送给浏览器。若是请求的是动态数据 /index.php，nginx须要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串要有吧，POST数据也要有吧，HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。

 

那么CGI程序的性能问题在哪呢？PHP解析器会解析php.ini文件，初始化执行环境，就是这里了。标准的CGI对每一个请求都会执行这些步骤（不闲累啊！启动进程很累的说！），因此处理的时间会比较长。这明显不合理嘛！那么Fastcgi是怎么作的呢？

 

首先，Fastcgi会先启一个master，解析配置文件，初始化执行环境，

 

而后再启动多个worker。当请求过来时，master会传递给一个worker，

而后当即能够接受下一个请求。这样就避免了重复的劳动，效率天然是高。

并且当worker不够用时，master能够根据配置预先启动几个worker等着；

固然空闲worker太多时，也会停掉一些，这样就提升了性能，也节约了资源。这就是fastcgi的对进程的管理。

PHP-FPM是一个实现了Fastcgi的程序，PHP-FPM的管理对象是php-cgi。被PHP官方收了。

后来PHP内核集成了PHP-FPM以后就方便多了，使用 --enalbe-fpm这个编译参数便可。

PHP的解释器是php-cgi。

php-cgi只是个CGI程序，他本身自己只能解析请求，返回结果，不会进程管理（皇上，臣妾真的作不到啊！）

因此就出现了一些可以调度php-cgi进程的程序，好比说由lighthttpd分离出来的spawn-fcgi

。好了PHP-FPM也是这么个东东，在长时间的发展后，逐渐获得了你们的承认

（要知道，前几年你们但是抱怨PHP-FPM稳定性太差的），也愈来愈流行。