CGI，FastCGI，PHP-CGI與PHP-FPM(轉)

http://www.cnblogs.com/zl0372/articles/php_4.html

 

 

CGI

CGI全稱是「公共網關接口」(Common Gateway Interface)，HTTP服務器與你的或其它機器上的程序進行「交談」的一種工具，其程序須運行在網絡服務器上。

CGI自己能夠當作是一種協議標準，它能夠用任何一種語言編寫具體的符合該接口標準的協議存在，只要這種語言具備標準輸入、輸出和環境變量。如php,perl,tcl等。

 

FastCGI

FastCGI像是一個常駐(long-live)型的CGI，它能夠一直執行着，只要激活後，不會每次都要花費時間去fork一次（這是CGI最爲人詬病的fork-and-execute 模式）。它還支持分佈式的運算，即 FastCGI 程序能夠在網站服務器之外的主機上執行而且接受來自其它網站服務器來的請求。

FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行爲是將CGI解釋器進程保持在內存中並所以得到較高的性能。衆所周知，CGI解釋器的反覆加載是CGI性能低下的主要緣由，若是CGI解釋器保持在內存中並接受FastCGI進程管理器調度，則能夠提供良好的性能、伸縮性、Fail- Over特性等等。

FastCGI也能夠稱爲是一種協議標準，好比下面要說的php-fpm就是支持解析php的一個fastCGI進程管理器/引擎。

 

 

 

FastCGI特色

1. FastCGI具備語言無關性.
2. FastCGI在進程中的應用程序，獨立於核心web服務器運行，提供了一個比API更安全的環境。APIs把應用程序的代碼與核心的web服務器連接在一塊兒，這意味着在一個錯誤的API的應用程序可能會損壞其餘應用程序或核心服務器。 惡意的API的應用程序代碼甚至能夠竊取另外一個應用程序或核心服務器的密鑰。
3. FastCGI技術目前支持語言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相關模塊在Apache, ISS, Lighttpd等流行的服務器上也是可用的。
4. FastCGI的不依賴於任何Web服務器的內部架構，所以即便服務器技術的變化, FastCGI依然穩定不變。

FastCGI的工做原理

1. Web Server啓動時載入FastCGI進程管理器（IIS ISAPI或Apache Module)
2. FastCGI進程管理器自身初始化，啓動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的鏈接。
3. 當客戶端請求到達Web Server時，FastCGI進程管理器選擇並鏈接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。
4. FastCGI子進程完成處理後將標準輸出和錯誤信息從同一鏈接返回Web Server。當FastCGI子進程關閉鏈接時，請求便告處理完成。FastCGI子進程接着等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個鏈接。 在CGI模式中，php-cgi在此便退出了。

在上述狀況中，你能夠想象CGI一般有多慢。每個Web請求PHP都必須從新解析php.ini、從新載入所有擴展並重初始化所有數據結構。使用FastCGI，全部這些都只在進程啓動時發生一次。一個額外的好處是，持續數據庫鏈接(Persistent database connection)能夠工做。

FastCGI的不足

由於是多進程，因此比CGI多線程消耗更多的服務器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。

Nginx 0.8.46+PHP 5.2.14(FastCGI)服務器在3萬併發鏈接下，開啓的10個Nginx進程消耗150M內存（15M*10=150M），開啓的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。若是服務器內存較小，徹底能夠只開啓25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。
上面的數據摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建賽過Apache十倍的Web服務器(第6版)

PHP-CGI

PHP-CGI是PHP自帶的FastCGI管理器。

PHP-CGI的不足：

1. php-cgi變動php.ini配置後需重啓php-cgi才能讓新的php-ini生效，不能夠平滑重啓。
2. 直接殺死php-cgi進程，php就不能運行了。(PHP-FPM和Spawn-FCGI就沒有這個問題，守護進程會平滑重新生成新的子進程。）

PHP-FPM

PHP-FPM是一個PHP FastCGI管理器，是隻用於PHP的，能夠在 http://php-fpm.org/download下載獲得。

PHP-FPM實際上是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP後纔可使用。

如今咱們能夠在最新的PHP 5.3.2的源碼樹裏下載獲得直接整合了PHP-FPM的分支，聽說下個版本會融合進PHP的主分支去。相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，並且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。

PHP5.3.3已經集成php-fpm了，再也不是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，能夠有效控制內存和進程、能夠平滑重載PHP配置，比spawn-fcgi具備更多有點，因此被PHP官方收錄了。在./configure的時候帶 –enable-fpm參數便可開啓PHP-FPM。

Spawn-FCGI

Spawn-FCGI是一個通用的FastCGI管理服務器，它是lighttpd中的一部份，不少人都用Lighttpd的Spawn-FCGI進行FastCGI模式下的管理工做，不過有很多缺點。而PHP-FPM的出現多少緩解了一些問題，但PHP-FPM有個缺點就是要從新編譯，這對於一些已經運行的環境可能有不小的風險(refer)，在php 5.3.3中能夠直接使用PHP-FPM了。

Spawn-FCGI目前已經獨成爲一個項目，更加穩定一些，也給不少Web 站點的配置帶來便利。已經有很多站點將它與nginx搭配來解決動態網頁。

最新的lighttpd也沒有包含這一塊了(http://www.lighttpd.net/search?q=Spawn-FCGI)，但能夠在之前版本中找到它。在lighttpd-1.4.15版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)，目前Spawn-FCGI的下載地址是http://redmine.lighttpd.net/projects/spawn-fcgi，最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz。

注：最新的Spawn-FCGI能夠到lighttpd.net網站搜索「Spawn-FCGI」找到它的最新版本發佈地址。

PHP-FPM與spawn-CGI對比

PHP-FPM的使用很是方便，配置都是在PHP-FPM.ini的文件內，而啓動、重啓均可以從php/sbin/PHP-FPM中進行。更方便的是修改php.ini後能夠直接使用PHP-FPM reload進行加載，無需殺掉進程就能夠完成php.ini的修改加載
結果顯示使用PHP-FPM可使php有不小的性能提高。PHP-FPM控制的進程cpu回收的速度比較慢,內存分配的很均勻。
Spawn-FCGI控制的進程CPU降低的很快，而內存分配的比較不均勻。有不少進程彷佛未分配到，而另一些卻佔用很高。多是因爲進程任務分配的不均勻致使的。而這也致使了整體響應速度的降低。而PHP-FPM合理的分配，致使整體響應的提到以及任務的平均。

總結：

　　 f astCGI是nginx和php之間的一個通訊接口，該接口實際處理過程經過啓動php-fpm進程來解析php腳本，即 php-fpm至關於一個動態應用服務器，從而實現nginx動態解析php。所以，若是nginx服務器須要支持php解析，須要在nginx.conf中增長php的配置：將php腳本轉發到fastCGI進程監聽的IP地址和端口（php-fpm.conf中指定）。同時，php安裝的時候，須要開啓支持fastCGI選項，而且編譯安裝php-fpm補丁/擴展，同時，須要 啓動php-fpm進程，才能夠解析nginx經過fastCGI轉發過來的php腳本。

 

 

 

php-fpm是一個徹底獨立的程序,不依賴php-cgi,也不依賴php.由於php-fpm是一個內置了php解釋器的FastCGI服務,啓動時可以自行讀取php.ini配置和php-fpm.conf配置.

附:PHP FastCGI進程管理器PHP-FPM的架構
一個master進程,支持多個pool,每一個pool由master進程監聽不一樣的端口,pool中有多個worker進程.
每一個worker進程都內置PHP解釋器,而且進程常駐後臺,支持prefork動態增長.
每一個worker進程支持在運行時編譯腳本並在內存中緩存生成的opcode來提高性能.
每一個worker進程支持配置響應指定請求數後自動重啓,master進程會重啓掛掉的worker進程.
每一個worker進程能保持一個到MySQL/Memcached/Redis的持久鏈接,實現"鏈接池",避免重複創建鏈接,對程序透明.
master進程採用epoll模型異步接收和分發請求,listen監聽端口,epoll_wait等待鏈接,
而後分發給對應pool裏的worker進程,worker進程accpet請求後poll處理鏈接,
若是worker進程不夠用,master進程會prefork更多進程,
若是prefork達到了pm.max_children上限,worker進程又全都繁忙,
這時master進程會把請求掛起到鏈接隊列backlog裏(默認值是511).

 

 

web server（好比說nginx）只是內容的分發者。好比，若是請求/index.html，那麼web server會去文件系統中找到這個文件，發送給瀏覽器，這裏分發的是靜態數據。好了，若是如今請求的是/index.php，根據配置文件，nginx知道這個不是靜態文件，須要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些數據給PHP解析器呢？url要有吧，查詢字符串也得有吧，POST數據也要有，HTTP header不能少吧，好的，CGI就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。仔細想一想，你在PHP代碼中使用的用戶從哪裏來的。

當web server收到/index.php這個請求後，會啓動對應的CGI程序，這裏就是PHP的解析器。接下來PHP解析器會解析php.ini文件，初始化執行環境，而後處理請求，再以規定CGI規定的格式返回處理後的結果，退出進程。web server再把結果返回給瀏覽器。

     好了，CGI是個協議，跟進程什麼的不要緊。那fastcgi又是什麼呢？Fastcgi是用來提升CGI程序性能的。

提升性能，那麼CGI程序的性能問題在哪呢？"PHP解析器會解析php.ini文件，初始化執行環境"，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理每一個時間的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，而後當即能夠接受下一個請求。這樣就避免了重複的勞動，效率天然是高。並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。

    那PHP-FPM又是什麼呢？是一個實現了Fastcgi的程序，被PHP官方收了。

你們都知道，PHP的解釋器是php-cgi。php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離出來的spawn-fcgi。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。

 

fastcgi是一個協議，php-fpm實現了這個協議

    

php-fpm的 管理對象 是php-cgi。但不能說php-fpm是fastcgi進程的管理器，由於前面說了fastcgi是個協議，

之前php-fpm沒有包含在PHP內核裏面，要使用這個功能，須要找到與源碼版本相同的php-fpm對內核打補丁，而後再編譯。

後來PHP內核集成了PHP-FPM以後就方便多了，使用--enalbe-fpm這個編譯參數便可。

    有的說，修改了php.ini配置文件後，沒辦法 平滑重啓，因此就誕生了php-fpm

是的，修改php.ini以後，php-cgi進程的確是沒辦法平滑重啓的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就能夠歇着了，經過這種機制來平滑過分。

     還有的說PHP-CGI是PHP自帶的FastCGI管理器，那這樣的話幹嘛又弄個php-fpm出

不對。php-cgi只是解釋PHP腳本的程序而已。    

 

 

 

 

 

FastCGI像是一個常駐(long-live)型的CGI，是用來提升CGI程序性能的。CGI是通用網關接口，是外部應用程序與Web 服務器之間的接口標準，CGI是爲了保證web server傳遞過來的數據是標準格式的，方便CGI程序的編寫者。若是請求的是靜態數據 /index.html，那麼web server會去文件系統找到這個文件發送給瀏覽器。若是請求的是動態數據 /index.php，nginx須要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些數據給PHP解析器呢？url要有吧，查詢字符串要有吧，POST數據也要有吧，HTTP header不能少吧，好的，CGI就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。

 

那麼CGI程序的性能問題在哪呢？PHP解析器會解析php.ini文件，初始化執行環境，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？

 

首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，

 

而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，

而後當即能夠接受下一個請求。這樣就避免了重複的勞動，效率天然是高。

並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；

固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。

PHP-FPM是一個實現了Fastcgi的程序，PHP-FPM的管理對象是php-cgi。被PHP官方收了。

後來PHP內核集成了PHP-FPM以後就方便多了，使用 --enalbe-fpm這個編譯參數便可。

PHP的解釋器是php-cgi。

php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）

因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離出來的spawn-fcgi

。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認

（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。