标签：
PHP运行模式
PHP运行模式，就是PHP的执行方式，一种是独立的可执行程序(通常是exe程序)，一种是以模块的形式嵌入到服务器程序里运行(通常是DLL程序)。
独立执行，用到的是CGI(Common Gateway Interface，通用网关接口)技术；而另外一种，在IIS里被称为ISAPI(Internet Server Application Programming Interface，因特网服务器应用程序接口)，Apache里则被称为Module(模块)，比较通俗一点。通常来讲，技术的执行就叫做模式，CGI是一种技术也是一种模式。
IIS: CGI/ISAPI
Apache: CGI/Module
两种方法的区别
在CGI模式下，当收到一个匹配URL的请求，相应的程序就会被调用，并将客户端发送的数据作为输入；
而在模块化(DLL)中，PHP是与Web服务器一起启动并运行的；
在CGI中，执行程序与服务器程序各自独立，当执行程序出现错误时，服务器程序不会受到影响，但会占用更多的资源。
所以，CGI比DLL有更好的稳定性和安全性，而DLL则有更好的执行效率和速度。
FastCGI的好处
1)可以支持在一个系统上支持同一种脚本不同版本的解释器,如PHP4, PHP5
2)只要安装一个apache 的module后，就可同时支持PHP, Python, Perl等，没有必要为它们安装各自的module
3)获得更好的权限控制，比PHP运行在安全模式更安全，国外大的虚拟主机供应商如DreamHost,BlueHost, Godaddy等都是采用
FastCGI
FastCGI的引入就是为了解决CGI的性能问题，严格来说，FastCGI也是CGI的一种，它在保留CGI的稳定性的同时，结合了DLL的优点。
FastCGI
是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是
CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over特性等
等。
普通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解释器？
这可能出于多方面的考虑，例如：
1、你无论如何也不能在windows平台上稳定的使用多线程CGI解释器，无论是IIS ISAPI方式还是APACHE Module方式，它们总是运行一段时间就崩溃了。奇怪么？但是确实存在这样的情况！
当
然，也有很多时候你能够稳定的使用多线程CGI解释器，但是，你有可能发现网页有时候会出现错误，无论如何也找不到原因，而换用FastCGI方式时这种
错误的概率会大大的降低。我也不清楚这是为什么，我想独立地址空间的CGI解释器可能终究比共享地址空间的形式来得稳定一点点。
2、
性能！性能？可能么，难道FastCGI比多线程CGI解释器更快？但有时候确实是这样，只有测试一下你的网站，才能最后下结论。原因嘛，我觉得很难讲，
但有资料说在Zend WinEnabler的时代，Zend原来也是建议在Windows平台下使用FastCGI而不是IIS
ISAPI或Apache Module，不过现在Zend已经不做这个产品了。
不使用FastCGI的理由
1、多进程比多线程消耗更多的服务器内存，php-cgi.exe解释器每进程消耗7至25兆内存，将这个数字乘以50或100试试。
2、性能。确实有时候多线程CGI解释器更快，呵呵，而且有时候，它也很稳定。
相对于传统的CGI模式，
mod_php 的优势就是用多线程模式来应对请求，每次执行完后，线程消失，所有资源消失。存在的问题是其中一个线程可能会搞死主进程，造成server宕机。且大量逻辑计算会影响主进程的相应速度；
fastcgi的优势是主server进程通过socket与cgi管理器通信，cgi管理器从cgi进程池中安排其中一个cgi进程进行处理，处 理完毕后这个cgi进程回收资源但是不退出，等待下一个处理。这样即使cgi进程崩溃，也完全不会影响server进程。且server的计算更加单纯， 只负责收发数据。相当于是一种负载均衡解决方案，可以支撑大量访问。但是我觉得存在的问题是因为cgi进程不会退出，可能其稳定性会存在问题，比如回收不 彻底等，会造成其崩溃，所以虽然主server进程不挂，但是处理某一个人的计算的时候，可能会针对这个请求挂掉，所以稳定性并不是完全可靠。
参考：http://www.v2ex.com/t/160602
标签：
原文地址：http://www.cnblogs.com/Alight/p/4711318.html
