php cgi fastcgi php_mod比较

转自：http://samuschen.iteye.com/blog/803923

先了解一下普通cgi的工作流程：

web server收到用户请求，并把请求提交给cgi程序，cgi程序根据请求提交的参数作相应处理，然后输出标准的html语句返回给web server，web server再返回给客户端，这就是普通cgi的工作原理。

从 上面看，cgi所要实现的不过是动态网页而已，这种处理方式的特点就是每接到一个请求，web server都要fork出一个单独的cgi程序的进程来处理，这种方式的好处是把web server和具体的程序处理独立开来，结构清晰，可控性强，同时缺点就是如果在高访问需求的情况下，cgi的进程fork就会成为很大的服务器负担，想 象一下数百个并发请求导致服务器fork出数百个进程就明白了。这也是为什么cgi一直背负性能低下，高资源消耗的恶名的原因。

相应的有问题就有解决方案，目前流行的方案就是使用模块设计，基本上目前的web server都有相应的模块机制来扩充它的

功能， 只要按照其设计规范设计出来的模块，就能插入到web server自身的进程处理，因此性能有很大改观，例如IIS的isapi，apache的dso。但是，这种方法也不是没有缺点的，例如对于不同的 web server，要按照不同标准开发，无法做到webserver无关性；例如这将输入验证的工作转交给了web server，没办法自由处理；例如一旦出现问题将影响整个web server处理流程；例如插入web server进程导致的无法以多用户标示运行，无法处理虚拟主机权限等。

所幸我们还有另外的选择，这就是fastcgi。 fastcgi是基于cgi架构的扩展，他的核心思想就是在web server和具体cgi程序之间建立一个智能的可持续的中间层，统管cgi程序的运行，这样web server只需要将请求提交给这个层，这个层再派生出几个可复用的cgi程序实例，然后再把请求分发给这些实例，这些实例是可控的，可持续，可复用的， 因此一方面避免了进程反复fork，另一方面又可以通过中间层的控制和探测机制来监视这些实例的运行情况，根据不同的状况fork或者回收实例，达到灵活 性和稳定性兼得的目的。

本人曾经做过测试，使用cgi方式运行php效率最差，mod_php方式性能非常不错，几乎是cgi方 式的50倍，但是无法保证虚拟主机站点的安全性隔离，而fastcgi性能则基本和mod_php相当，这还是在使用了suexec切换虚拟主机站点运行 用户的情况下的结果。

fastcgi与cgi的区别

先讲下cgi：

cgi在2000年或更早的时候用得比较多， 以前web服务器一般只处理静态的请求，如果碰到一个动态请求怎么办呢？web服务器会把根据这次请求的内容，然后会fork一个新进程运行外部c程序 （或perl脚本...）， 这个进程会把处理完的数据返回给web服务器，最后web服务器把内容发送给用户，刚才fork的进程也随之退出。 如果下次用户还请求改动态脚本，那么web服务器又再次fork一个新进程，周而复始的进行。

后来出现了一种更高级的方式是， web服务器可以内置perl解释器或php解释器。 也就是说这些解释器做成模块的方式，web服务器会在启动的时候就启动这些解释器。 当有新的动态请求进来时，web服务器就是自己解析这些perl或php脚本，省得重新fork一个进程，效率提高了。

fastcgi的方式是，web服务器收到一个请求时，他不会重新fork一个进程（因为这个进程在web服务器启动时就开启了，而且不会退 出），web服务器直接把内容传递给这个进程（进程间通信，但fastcgi使用了别的方式，tcp方式通信），这个进程收到请求后进行处理，把结果返回 给web服务器，最后自己接着等待下一个请求的到来，而不是退出。

fastcgi跟cgi的区别是：

在web服务器方面在对数据进行处理的进程方面

cgi fork一个新的进程进行处理 读取参数，处理数据，然后就结束生命期

fastcgi 用tcp方式跟远程机子上的进程或本地进程建立连接 要开启tcp端口，进入循环，等待数据的到来，处理数据