PHP運行模式

1、運行模式

關於PHP目前比較常見的五大運行模式:

1)CGI(通用網關接口 / Common Gateway Interface)

2)FastCGI(常駐型CGI / Long-Live CGI)

3)CLI(命令行運行 / Command Line Interface)

4)Web模塊模式(Apache等Web服務器運行的模式)

5)ISAPI(Internet Server Application Program Interface)

備註:在PHP5.3以後,PHP不再有ISAPI模式,安裝後也不再有php5isapi.dll這個文件。要在IIS6上使用高版本PHP,必須安裝FastCGI 擴展,然後使IIS6支持FastCGI。

1.1 CGI模式

  CGI即通用網關接口(Common Gateway Interface),它是一段程序,通俗的講CGI就象是一座橋,把網頁和Web服務器中的執行程序連接起來,它把HTML接收的指令傳遞給服務器的執行程序,再把服務器執行程序的結果返還給HTML頁。CGI 的跨平臺性能極佳,幾乎可以在任何操作系統上實現。 CGI已經是比較老的模式了,這幾年都很少用了。

  每有一個用戶請求,都會先要創建CGI的子進程,然後處理請求,處理完後結束這個子進程,這就是Fork-And-Execute模式。 當用戶請求數量非常多時,會大量擠佔系統的資源如內存,CPU時間等,造成效能低下。所以用CGI方式的服務器有多少連接請求就會有多少CGI子進程,子進程反覆加載是CGI性能低下的主要原因。

  如果不想把 PHP 嵌入到服務器端軟件(如 Apache)作爲一個模塊安裝的話,可以選擇以 CGI 的模式安裝。或者把 PHP 用於不同的 CGI 封裝以便爲代碼創建安全的 chroot 和 setuid 環境。這樣每個客戶機請求一個PHP文件,Web服務器就調用php.exe(win下是php.exe,linux是php)去解釋這個文件,然後再把解釋的結果以網頁的形式返回給客戶機。 這種安裝方式通常會把 PHP 的可執行文件安裝到 web 服務器的 cgi-bin 目錄。CERT 建議書 CA-96.11 建議不要把任何的解釋器放到 cgi-bin 目錄。

  這種方式的好處是把Web Server和具體的程序處理獨立開來,結構清晰,可控性強,同時缺點就是如果在高訪問需求的情況下,CGI的進程Fork就會成爲很大的服務器負擔,想 象一下數百個併發請求導致服務器Fork出數百個進程就明白了。這也是爲什麼CGI一直揹負性能低下,高資源消耗的惡名的原因。

CGI模式安裝:
CGI已經是比較老的模式了,這幾年都很少用了,所以我們只是爲了測試。
安裝CGI模式需要註釋掉
LoadModule php5_module modules/libphp5.so 這行。如果不註釋這行會一直走到handler模式。也就是模塊模式。
然後在httpd.conf增加action:
Action application/x-httpd-php /cgi-bin/
如果在/cgi-bin/目錄找不到php-cgi.可自行從php的bin裏面cp一個。
然後重啓apache,再打開測試頁面發現Server API變成:CGI/FastCGI。說明成功切換爲cgi模式。
問題:
1)  如果cgi程序放在/usr/local/httpd/cgi-bin/裏無法執行,遇到403或500錯誤的話
打開apache錯誤日誌 有如下提示: Permission denied: exec of
可以檢查cgi程序的屬性,按Linux contexts文件 裏定義的,/usr/local/httpd/cgi-bin/裏必須是httpd_sys_script_exec_t 屬性。  通過ls -Z查看,如果不是則通過如下命令更改: chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/*.cgi 如果是虛擬主機裏的cgi,則參考問題2使之能正常使用普通的功能後,再通過chcon設置cgi文件的context爲
httpd_sys_script_exec_t即可。chcon -R -t httpd_sys_script_exec_t cgi-bin/
2) apache錯誤提示:.... malformed header from script. Bad header=
根據提示說明有header有問題,查看文件輸出的第一句話是什麼,應該類似於如下
Content-type: text/plain; charset=iso-8859-1\n\n
或者Content-type:text/html\n\n
注意:聲明好Content-type後要輸出兩個空行。
3)apache錯誤提示: Exec format error
腳本解釋器設置錯誤。腳本第一行應該以'#!解釋器路徑'的形式, 填寫腳本解釋器的路徑,如果是PERL程序,常見的路徑爲: #!/usr/bin/perl 或 #!/usr/local/bin/perl   如果是PHP程序,不需要填寫解釋器路徑,系統會自動找到PHP。

1.2 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就是很大的內存數。

安裝fastcgi模式:
安裝apache路徑是/usr/local/httpd/
安裝php路徑是/usr/local/php/
1)安裝mod_fastcgi
wget http://www.fastcgi.com/dist/mod_fastcgi-2.4.6.tar.gz
tar zxvf mod_fastcgi-2.4.6.tar.gz
cd mod_fastcgi-2.4.6
cp Makefile.AP2 Makefile
vi Makefile,編輯top_dir = /usr/local/httpd
make
make install
安裝完後,
/usr/local/httpd/modules/多出一個文件:mod_fcgid.so
2)重新編譯php
./configure --prefix=/usr/local/php --enable-fastcgi --enable-force-cgi-redirect --disable-cli
make
make install
這樣編譯後,在PHP的bin目錄下的php-cgi就是fastcgi模式的php解釋器了
安裝成功後,執行
php -v 輸出
PHP 5.3.2 (cgi-fcgi).
這裏輸出帶了cgi-fcgi
注意:
1.編譯參數不能加 –with-apxs=/usr/local/httpd/bin/apxs 否則安裝出來的php執行文件是cli模式的
2 如果編譯時不加--disable-cli則輸出 PHP 5.3.2(cli)

3)配置apache
需要配置apache來以fastcgi模式運行php程序
vi httpd.conf

#加載fastcgi模塊
LoadModule fastcgi_module modules/mod_fastcgi.so
#//以靜態方式執行fastcgi 啓動了10進程
FastCgiServer /usr/local/php/bin/php-cgi  -processes 10 -idle-timeout 150 -pass-header HTTP_AUTHORIZATION
<VirtualHost *:80>
 #
 DocumentRoot   /usr/local/httpd/fcgi-bin  
 ServerName www.fastcgitest.com

 ScriptAlias /fcgi-bin/   /usr/local/php/bin/   #定義目錄映射 /fcgi-bin/ 代替 /usr/local/php/bin/
 Options +ExecCGI
 AddHandler fastcgi-script .php .fcgi #.php結尾的請求都要用php-fastcgi來處理 
 AddType application/x-httpd-php .php #增加MIME類型
 Action application/x-httpd-php /fcgi-bin/php-cgi  #設置php-fastcgi的處理器: /usr/local/php/bin/php-cgi
 <Directory /usr/local/httpd/fcgi-bin/>
  Options Indexes ExecCGI
  Order allow,deny
  allow from all
 </Directory>
</VirtualHost>

1.3 CLI模式

  PHP-CLI是PHP Command Line Interface的簡稱,如同它名字的意思,就是PHP在命令行運行的接口,區別於在Web服務器上運行的PHP環境(PHP-CGI,ISAPI等)。 也就是說,PHP不單可以寫前臺網頁,它還可以用來寫後臺的程序。 PHP的CLI Shell腳本適用於所有的PHP優勢,使創建要麼支持腳本或系統甚至與GUI應用程序的服務端,在Windows和Linux下都是支持PHP-CLI模式的。

  【優點】

1)使用多進程,子進程結束以後,內核會負責回收資源;

2)使用多進程,子進程異常退出不會導致整個進程Thread退出,父進程還有機會重建流程;

3)一個常駐主進程,只負責任務分發,邏輯更清楚。

  我們在Linux下經常使用"php –m"查找PHP安裝了那些擴展就是PHP命令行運行模式;有興趣的同學可以輸入"php –h"去深入研究該運行模式。

1.4 模塊模式

  模塊模式是以mod_php5模塊的形式集成,此時mod_php5模塊的作用是接收Apache傳遞過來的PHP文件請求,並處理這些請求,然後將處理後的結果返回給Apache。如果我們在Apache啓動前在其配置文件中配置好了PHP模塊(mod_php5), PHP模塊通過註冊apache2的ap_hook_post_config掛鉤,在Apache啓動的時候啓動此模塊以接受PHP文件的請求。

  除了這種啓動時的加載方式,Apache的模塊可以在運行的時候動態裝載,這意味着對服務器可以進行功能擴展而不需要重新對源代碼進行編譯,甚至根本不需要停止服務器。我們所需要做的僅僅是給服務器發送信號HUP或者AP_SIG_GRACEFUL通知服務器重新載入模塊。但是在動態加載之前,我們需要將模塊編譯成爲動態鏈接庫。此時的動態加載就是加載動態鏈接庫。 Apache中對動態鏈接庫的處理是通過模塊mod_so來完成的,因此mod_so模塊不能被動態加載,它只能被靜態編譯進Apache的核心。這意味着它是隨着Apache一起啓動的。

  Apache是如何加載模塊的呢?我們以前面提到的mod_php5模塊爲例。首先我們需要在Apache的配置文件httpd.conf中添加一行:

LoadModule php5_module modules/mod_php5.so

  這裏我們使用了LoadModule命令,該命令的第一個參數是模塊的名稱,名稱可以在模塊實現的源碼中找到。第二個選項是該模塊所處的路徑。如果需要在服務器運行時加載模塊,可以通過發送信號HUP或者AP_SIG_GRACEFUL給服務器,一旦接受到該信號,Apache將重新裝載模塊,而不需要重新啓動服務器。

  該運行模式是我們以前在windows環境下使用apache服務器經常使用的,而在模塊化(DLL)中,PHP是與Web服務器一起啓動並運行的。(它是apache在CGI的基礎上進行的一種擴展,加快PHP的運行效率)。

1.5 ISAPI模式

  ISAPI(Internet Server Application Program Interface)是微軟提供的一套面向Internet服務的API接口,一個ISAPI的DLL,可以在被用戶請求激活後長駐內存,等待用戶的另一個請求,還可以在一個DLL裏設置多個用戶請求處理函數,此外,ISAPI的DLL應用程序和WWW服務器處於同一個進程中,效率要顯著高於CGI。(由於微軟的排他性,只能運行於windows環境)

  PHP作爲Apache模塊,Apache服務器在系統啓動後,預先生成多個進程副本駐留在內存中,一旦有請求出現,就立即使用這些空餘的子進程進行處理,這樣就不存在生成子進程造成的延遲了。這些服務器副本在處理完一次HTTP請求之後並不立即退出,而是停留在計算機中等待下次請求。對於客戶瀏覽器的請求反應更快,性能較高。

5.php在Nginx中運行模式(Nginx+ PHP-FPM)
使用FastCGI方式現在常見的有兩種stack:ligthttpd+spawn-fcgi;另外一種是nginx+PHP-FPM(也可以用spawn-fcgi)。
A、如上面所說該兩種結構都採用FastCGI對PHP支持,因此HTTPServer完全解放出來,可以更好地進行響應和併發處理。因此lighttpd和nginx都有small, but powerful和efficient的美譽。
B、該兩者還可以分出一個好壞來,spawn-fcgi由於是lighttpd的一部分,因此安裝了lighttpd一般就會使用spawn-fcgi對php支持,但是目前有用戶說ligttpd的spwan-fcgi在高併發訪問的時候,會出現上面說的內存泄漏甚至自動重啓fastcgi。即:PHP腳本處理器當機,這個時候如果用戶訪問的話,可能就會出現白頁(即PHP不能被解析或者出錯)。

另一個:首先nginx不像lighttpd本身含帶了fastcgi(spawn-fcgi),因此它完全是輕量級的,必須藉助第三方的FastCGI處理器纔可以對PHP進行解析,因此其實這樣看來nginx是非常靈活的,它可以和任何第三方提供解析的處理器實現連接從而實現對PHP的解析(在nginx.conf中很容易設置)。nginx可以使用spwan-fcgi(需要一同安裝lighttpd,但是需要爲nginx避開端口,一些較早的blog有這方面安裝的教程),但是由於spawn-fcgi具有上面所述的用戶逐漸發現的缺陷,現在慢慢減少使用nginx+spawn-fcgi組合了。

C、由於spawn-fcgi的缺陷,現在出現了新的第三方(目前還是,聽說正在努力不久將來加入到PHP core中)的PHP的FastCGI處理器,叫做PHP-FPM(具體可以google)。它和spawn-fcgi比較起來有如下優點:
由於它是作爲PHP的patch補丁來開發的,安裝的時候需要和php源碼一起編譯,也就是說編譯到php core中了,因此在性能方面要優秀一些;
同時它在處理高併發方面也優於spawn-fcgi,至少不會自動重啓fastcgi處理器。具體採用的算法和設計可以google瞭解。

因此,如上所說由於nginx的輕量和靈活性,因此目前性能優越,越來越多人逐漸使用這個組合:nginx+PHP/PHP-FPM
6.總結
目前在
HTTPServer這塊基本可以看到有三種stack比較流行:
(1)Apache+mod_php5
(2)lighttp+spawn-fcgi
(3)nginx+PHP-FPM
三者後兩者性能可能稍優

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章