FastCGI模式優點和缺點
FastCGI是CGI的升級版本,FastCGI像是一個常駐 (long-live)型的 CGI,它可以一直執行著,只要激活后,不會每次都要花費時間去 Fork 一次 (這是 CGI 最為人詬病的 fork-and-execute 模式)。
FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間通信的接口。多數流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,同時,FastCGI也被許多腳本語言所支持,其中就有PHP。
FastCGI接口方式采用C/S結構,可以將HTTP服務器和腳本解析服務器分開,同時在腳本解析服務器上啟動一個或者多個腳本解析守護進程。當HTTP服務器每次遇到動態程序時,可以將其直接交付給FastCGI進程來執行,然后將得到的結果返回給瀏覽器。這種方式可以讓HTTP服務器專一地處理靜態請求或者將動態腳本服務器的結果返回給客戶端,這在很大程度上提高了整個應用系統的性能。
【原理】
1)Web Server啟動時載入FastCGI進程管理器(IIS ISAPI或Apache Module);
2)FastCGI進程管理器自身初始化,啟動多個CGI解釋器進程 (可見多個php-cgi.exe或php-cig)并等待來自Web Server的連接;
3)當客戶端請求到達Web Server時,FastCGI進程管理器選擇并連接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi;
4)FastCGI子進程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時,請求便告處理完成。FastCGI子進程接著等待并處理來自FastCGI進程管理器(運行在 WebServer中)的下一個連接。在正常的CGI模式中,php-cgi.exe在此便退出了。
在CGI模式中,你可以想象 CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部dll擴展并重初始化全部數據結構。使用FastCGI,所有這些都只在進程啟動時發生一次。一個額外的好處是,持續數據庫連接(Persistent database connection)可以工作。
備注:PHP的FastCGI進程管理器是PHP-FPM(PHP-FastCGI Process Manager)
【優點】
1)從穩定性上看,FastCGI是以獨立的進程池來運行CGI,單獨一個進程死掉,系統可以很輕易的丟棄,然后重新分配新的進程來運行邏輯;
2)從安全性上看,FastCGI支持分布式運算。FastCGI和宿主的Server完全獨立,FastCGI怎么down也不會把Server搞垮;
3)從性能上看,FastCGI把動態邏輯的處理從Server中分離出來,大負荷的IO處理還是留給宿主Server,這樣宿主Server可以一心一意作IO,對于一個普通的動態網頁來說, 邏輯處理可能只有一小部分,大量的是圖片等靜態。
【缺點】
說完了好處,也來說說缺點。從我的實際使用來看,用FastCGI模式更適合生產環境的服務器。但對于開發用機器來說就不太合適。因為當使用 Zend Studio調試程序時,由于 FastCGI會認為 PHP進程超時,從而在頁面返回 500錯誤。這一點讓人非常惱火,所以我在開發機器上還是換回了 ISAPI模式。對某些服務器的新版本支持不好,對分布式負載均衡沒要求的模塊化安裝是否是更好的選擇。目前的FastCGI和Server溝通還不夠智能,一個FastCGI進程如果執行時間過長會被當成是死進程殺掉重起,這樣在處理長時間任務的時候很麻煩,這樣做也使得FastCGI無法允許聯機調試。因為是多進程,所以比CGI多線程消耗更多的服務器內存,PHP-CGI解釋器每進程消耗7至25兆內存,將這個數字乘以50或100就是很大的內存數。

