一、fastcgi是什么？
fastcgi是语言无关的、可伸缩架构的cgi开放扩展，其主要 行为是将cgi解释器进程保持在内存中并因此获得较高的性能。众所周知，cgi解释器的反复加载是cgi性能低下的主要原因，如果cgi解释器保持在内存 中并接受fastcgi进程管理器调度，则可以提供良好的性能、伸缩性、fail-over特性等等。
fastcgi的官方站点在http://www.fastcgi.com
fastcgi的工作原理是：
1、web server 启动时载入fastcgi进程管理器（iis isapi或apache module）;
2、fastcgi进程管理器自身初始化，启动多个cgi解释器进程 (在任务管理器中可见多个php-cgi.exe)并等待来自web server的连接。
3、当客户端请求到达web server时，fastcgi进程管理器选择并连接到一个cgi解释器。web server将cgi环境变量和标准输入发送到fastcgi子进程php-cgi.exe。
4、fastcgi子进程完成处理后将标准输出和错误信息从同一连接返回web server。当fastcgi子进程关闭连接时，请求便告处理完成。fastcgi子进程接着等待并处理来自fastcgi进程管理器（运行在 webserver中）的下一个连接。 在正常的cgi模式中，php-cgi.exe在此便退出了。
在上述情况中，你可以想象 cgi通常有多慢。每一个web请求php都必须重新解析php.ini、重新载入全部dll扩展并重初始化全部数据结构。使用fastcgi，所有这些 都只在进程启动时发生一次。一个额外的好处是，持续数据库连接(persistent database connection)可以工作。
二、为什么要使用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解释器更快，呵呵，而且有时候，它也很稳定。