FastCGI 是什么？
FastCGI 是语言无关的、可伸缩架构的 CGI 开放扩展，其主要行为是将 CGI 解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI 解释器的反复加载是 CGI 性能低下的主要原因，如果 CGI 解释器保持在内存中并接受 FastCGI 进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over（故障切换）特性等等。
FastCGI 的官方站点在
FastCGI 工作原理
- Web Server 启动时载入 FastCGI 进程管理器（IIS ISAPI 或 Apache Module）；
- FastCGI 进程管理器自身初始化，启动多个 CGI 解释器进程 (在任务管理器中可见多个 php-cgi.exe)并等待来自 Web Server 的连接。
- 当客户端请求到达 Web Server 时，FastCGI 进程管理器选择并连接到一个 CGI 解释器。Web server 将 CGI 环境变量和标准输入发送到 FastCGI 子进程 php-cgi.exe。
- 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 解释器可能终究比共享地址空间的形式来得稳定一点点。
- 性能！性能？可能么，难道 FastCGI 比多线程 CGI 解释器更快？但有时候确实是这样，只有测试一下你的网站，才能最后下结论。原因嘛，我觉得很难讲，但有资料说在 Zend WinEnabler 的时代，Zend 原来也是建议在 Windows 平台下使用 FastCGI 而不是 IIS ISAPI 或 Apache Module，不过现在 Zend 已经不做这个产品了。
不使用 FastCGI 的理由
- 多进程比多线程消耗更多的服务器内存，php-cgi.exe 解释器每进程消耗 7 至 25 兆内存，将这个数字乘以 50 或 100 试试。
- 性能。确实有时候多线程 CGI 解释器更快，呵呵，而且有时候，它也很稳定。
- CGI？听起来就很土，呵呵