一、FastCGI是什么？
FastCGI是語言無關(guān)的、可伸縮架構(gòu)的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內(nèi)存中并因此獲得較高的性能。眾所周知，CGI解釋器的反復(fù)加載是CGI性能低下的主要原因，如果CGI解釋器保持在內(nèi)存中并接受FastCGI進程管理器調(diào)度，則可以提供良好的性能、伸縮性、Fail-Over特性等等。
FastCGI的官方站點在http://www.fastcgi.com
FastCGI的工作原理是：
1、Web Server 啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Module,nginx 下 fastcgi 與服務(wù)器是分離的，fastcgi 可有 lighttpd 下的 spawan-cgi或者 php-fpm 來管理））;
2、FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程 (在任務(wù)管理器中可見多個php-cgi.exe)并等待來自Web Server的連接。
3、當客戶端請求到達Web Server時，FastCGI進程管理器選擇并連接到一個CGI解釋器。Web server將CGI環(huán)境變量和標準輸入發(fā)送到FastCGI子進程php-cgi.exe。
4、FastCGI子進程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關(guān)閉連接時，請求便告處理完成。FastCGI子進程接著等待并處理來自FastCGI進程管理器（運行在WebServer中）的下一個連接。 在正常的CGI模式中，php-cgi.exe在此便退出了。
在上述情況中，你可以想象CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部dll擴展并重初始化全部數(shù)據(jù)結(jié)構(gòu)。使用FastCGI，所有這些都只在進程啟動時發(fā)生一次。一個額外的好處是，持續(xù)數(shù)據(jù)庫連接(Persistent database connection)可以工作。
二、為什么要使用FastCGI，而不是多線程CGI解釋器？
這可能出于多方面的考慮，例如：
1、你無論如何也不能在windows平臺上穩(wěn)定的使用多線程CGI解釋器，無論是IIS ISAPI方式還是APACHE Module方式，它們總是運行一段時間就崩潰了。奇怪么？但是確實存在這樣的情況！
當然，也有很多時候你能夠穩(wěn)定的使用多線程CGI解釋器，但是，你有可能發(fā)現(xiàn)網(wǎng)頁有時候會出現(xiàn)錯誤，無論如何也找不到原因，而換用FastCGI方式時這種錯誤的概率會大大的降低。我也不清楚這是為什么，我想獨立地址空間的CGI解釋器可能終究比共享地址空間的形式來得穩(wěn)定一點點。
2、性能！性能？可能么，難道FastCGI比多線程CGI解釋器更快？但有時候確實是這樣，只有測試一下你的網(wǎng)站，才能最后下結(jié)論。原因嘛，我覺得很難講，但有資料說在Zend WinEnabler的時代，Zend原來也是建議在Windows平臺下使用FastCGI而不是IIS ISAPI或Apache Module，不過現(xiàn)在Zend已經(jīng)不做這個產(chǎn)品了。
FastCGI的技術(shù)原理
如果想了解FastCGI的技術(shù)原理就要了解何為”短生存期應(yīng)用程序”,何為”長生存期應(yīng)用程序”。
先從CGI技術(shù)開刀，以下是CGI技術(shù)的理論：每次當客戶請求一個CGI的時候，Web服務(wù)器就請求操作系統(tǒng)生成一個新的CGI進程。當CGI滿足要求后，服務(wù)器就殺死這個進程。服務(wù)器對客戶端的每個請求都要重復(fù)這樣的過程?！ 《?span lang="EN-US">FastCGI技術(shù)的理論為：FastCGI程序一旦產(chǎn)生后，他可以持續(xù)工作,足夠滿足客戶的請求直到被明確的終止。如果你希望通過協(xié)同處理來提高程序的性能，你可以請求Web服務(wù)器運行多個FastCGI 應(yīng)用程序的副本。
CGI就是所謂的短生存期應(yīng)用程序，FastCGI就是所謂的長生存期應(yīng)用程序。
由于FastCGI程序并不需要不斷的產(chǎn)生新進程，可以大大降低服務(wù)器的壓力。并且產(chǎn)生較高的應(yīng)用效率。
自今，較為流行的Java語言Servlet技術(shù)在設(shè)計上是以參考FastCGI的技術(shù)運行所設(shè)計。
FastCGI的特點
1. 打破傳統(tǒng)頁面處理技術(shù)
傳統(tǒng)的頁面處理技術(shù)，程序必須與Web服務(wù)器或Application服務(wù)器處于同一臺服務(wù)器中。這種歷史已經(jīng)早N年被FastCGI技術(shù)所打破， FastCGI技術(shù)的應(yīng)用程序可以被安裝在服務(wù)器群中的任何一臺服務(wù)器，而通過TCP/IP協(xié)議與Web服務(wù)器通訊，這樣做既適合開發(fā)大型分布式Web 群，也適合高效數(shù)據(jù)庫控制。
2. 明確的請求模式
CGI技術(shù)沒有一個明確的角色，在FastCGI程序中，程序被賦予明確的角色（響應(yīng)器角色、認證器角色、過濾器角色）。
3. 合理的程序結(jié)構(gòu)
起初，真的很討厭FastCGI應(yīng)用程序的結(jié)構(gòu)要求。沒關(guān)系，您經(jīng)過一段時間編寫后就會喜歡這種結(jié)構(gòu)，只有這種完全規(guī)范的結(jié)構(gòu)才能讓您的程序更有效率。
Fastcgi到底是什么樣的技術(shù)
注:本人對LAMP,python了解不是很多,此文是我的個人理解,如果有誤忘告知
自從接觸rubyonrails以來,fastcgi這個技術(shù)標準就進入了我的視線,從技術(shù)角度看,fastcgi的優(yōu)點還是很多的,作為一種替代cgi的技術(shù)標準, fastcgi有如下優(yōu)點(穩(wěn)定,安全,高性能,方便擴展)
- 從穩(wěn)定性上看, fastcgi是以獨立的進程池運行來cgi,單獨一個進程死掉,系統(tǒng)可以很輕易的丟棄,然后重新分配新的進程來運行邏輯.
- 從安全性上看, fastcgi和宿主的server完全獨立, fastcgi怎么down也不會把server搞垮,
- 從性能上看, fastcgi把動態(tài)邏輯的處理從server中分離出來, 大負荷的IO處理還是留給宿主server, 這樣宿主server可以一心一意作IO,對于一個普通的動態(tài)網(wǎng)頁來說, 邏輯處理可能只有一小部分, 大量的圖片等靜態(tài)IO處理完全不需要邏輯程序的參與(注1)
- 從擴展性上講, fastcgi是一個中立的技術(shù)標準, 完全可以支持任何語言寫的處理程序(php,java,python…)
但是讓我感到迷惑不解的是,apache對fastcgi的支持mod_fastcgi簡直就是一塌糊涂, 最新的穩(wěn)定版本居然還是2003年的,snap也只到2004年, 在1.3下面還勉強可以用, 在apache2.0上更是被報告無法穩(wěn)定運行.fastcgi在[lighttpd][]上表現(xiàn)還算不錯, 但是lighttpd在用戶群,兼容性上還不夠主流(也就在linux上面表現(xiàn)不錯, 沒有正式的windows版本, solaris下面也有bug). 另外fastcgi也缺乏發(fā)展,讓人有被廢棄掉了的感覺.(ruby的dbi也是這個狀況). 和其他日新月異的技術(shù)標準比, fastcgi地位尷尬
直到我看到這篇文章才明白,fastcgi真是的命苦.(呵呵,以下的內(nèi)容取自該文章)
從名字上看fastcgi是fast的cgi的,屬于改良派.從理論上,他可以很多程序語言接口來開發(fā)動態(tài)web,但是這些程序語言每一個都是走完全革命的道路. java陣營就自己搞了一套j2ee server標準,要協(xié)作也直接找apache或者IIS談,瞧不上fastcgi. aspx直接和IIS是親兄弟,沒有fastcgi的份. 剩下的php因為太流行(LAMP),和apache是鐵哥們,一個mod_php就解決了,簡單方便, python社區(qū)的牛人太多,精力旺盛,人家搞了個SCGI玩,和fastcgi比是有過之而無不及. 等到rails出山的時候, fastcgi真的算是老態(tài)龍鐘了.
rails的出現(xiàn)使得fastcgi重新煥發(fā)了青春, apache也開始重新構(gòu)建新的mod_proxy_fcgi,但是它的前途還不能說是一片光明, 我覺得至少有以下幾個問題
- 目前的fastcgi和server溝通還不夠智能,一個fastcgi進程如果執(zhí)行時間過長會被當成是死進程殺掉重起,這樣在處理長時間任務(wù)的時候很麻煩.這樣做也使得fastcgi無法允許聯(lián)機調(diào)試.
- SCGI等類似技術(shù)的都可以替換fastcgi, SCGI在python中很成功,功能完備,目前SCGI也開始支持rails了
- 隨著rails的流行,一個獨立的mod_rails是可能出現(xiàn)的,而且ruby自身的webserver也開始涌現(xiàn),以后極有可能自己搞一套東西連接主流的webserver.fastcgi設(shè)計的時候是想作common gateway interface(cgi)的,但是這個目標的現(xiàn)在看來已經(jīng)不適合了
總結(jié): 我覺得fastcgi的前途不明朗, 但是目前來說,他也是rails唯一可以進入生產(chǎn)環(huán)境的工具,只用搞懂怎么配就可以了,沒有必要深入研究.
注1: 有時候邏輯也會參與圖片的生成,這時候圖片的IO處理就需要動態(tài)程序介入了,此時fastcgi技術(shù)上的優(yōu)勢雖然體現(xiàn)不出來,但是也不會比其他技術(shù)標準差.
from:http://www.opbsder.com/html/y2008/1141_fastcgi.html