一、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解釋器更快，呵呵，而且有時候，它也很穩定。
