一、FastCGI是什么？

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

FastCGI的官方站点在

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解释器更快，呵呵，而且有时候，它也很稳定。

更多信息请查看IT技术专栏