什么是 FastCGI

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