推薦：基于php在各種web服務器的運行模式詳解
本篇文章是對php在各種web服務器的運行模式進行了詳細的分析介紹，需要的朋友參考下

PHP運行模式有4鐘：
1）cgi 通用網關接口（Common Gateway Interface)）
2） fast-cgi 常駐 (long-live) 型的 CGI
3） cli 命令行運行 （Command Line Interface）
4）web模塊模式 （apache等web服務器運行的模塊模式）
1.CGI（Common Gateway Interface）
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。
2. Fastcgi模式
fast-cgi 是cgi的升級版本，FastCGI 像是一個常駐 (long-live) 型的 CGI，它可以一直執行著，只要激活后，不會每次都要花費時間去 fork 一次 (這是 CGI 最為人詬病的 fork-and-execute 模式)。
FastCGI的工作原理是：
(1)、Web Server啟動時載入FastCGI進程管理器【PHP的FastCGI進程管理器是PHP-FPM(php-FastCGI Process Manager)】（IIS ISAPI或Apache Module);
(2)、FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程 (在任務管理器中可見多個php-cgi.exe)并等待來自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)可以工作。
Fastcgi的優點：
1）從穩定性上看, fastcgi是以獨立的進程池運行來cgi,單獨一個進程死掉,系統可以很輕易的丟棄,然后重新分 配新的進程來運行邏輯.
2）從安全性上看,Fastcgi支持分布式運算. fastcgi和宿主的server完全獨立, fastcgi怎么down也不會把server搞垮.
3）從性能上看, fastcgi把動態邏輯的處理從server中分離出來, 大負荷的IO處理還是留給宿主server, 這樣宿主server可以一心一意作IO,對于一個普通的動態網頁來說, 邏輯處理可能只有一小部分, 大量的圖片等靜態
FastCGI缺點：說完了好處，也來說說缺點。從我的實際使用來看，用FastCGI模式更適合生產環境的服務器。但對于開發用機器來說就不太合適。因為當使用 Zend Studio調試程序時，由于 FastCGI會認為 PHP進程超時，從而在頁面返回 500錯誤。這一點讓人非常惱火，所以我在開發機器上還是換回了 ISAPI模式。
安裝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
我們使用虛擬機的方式實現：

或者

4）.restart 下apache,查看phpinfo，如果服務器信息是：
Apache/2.2.11 (Unix) mod_fastcgi/2.4.6之類的就說明安裝成功了。
如果出現403的錯誤，查看下/usr/local/httpd/fcgi-bin/是否有足夠的權限。
或者

改為：

就可以了。
ps -ef|grep php-cgi可以看見10個fastcgi進程在跑。
3. CLI模式
cli是php的命令行運行模式，大家經常會使用它，但是可能并沒有注意到（例如：我們在linux下經常使用 "php -m"查找PHP安裝了那些擴展就是PHP命令行運行模式；有興趣的同學可以輸入php -h去深入研究該運行模式）
1.讓 PHP 運行指定文件。
php script.php
php -f script.php
以上兩種方法（使用或不使用 -f 參數）都能夠運行腳本的script.php。您可以選擇任何文件來運行，您指定的 PHP 腳本并非必須要以 .php 為擴展名，它們可以有任意的文件名和擴展名。
2.在命令行直接運行 PHP 代碼。
php -r "print_r(get_defined_constants());"
在使用這種方法時，請您注意外殼變量的替代及引號的使用。
注: 請仔細閱讀以上范例，在運行代碼時沒有開始和結束的標記符！加上 -r 參數后，這些標記符是不需要的，加上它們會導致語法錯誤。
3.通過標準輸入（stdin）提供需要運行的 PHP 代碼。
以上用法給我們提供了非常強大的功能，使得我們可以如下范例所示，動態地生成 PHP 代碼并通過命令行運行這些代碼：
$ some_application | some_filter | php | sort -u >final_output.txt
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中添加一行：
該運行模式是我們以前在windows環境下使用apache服務器經常使用的，而在模塊化(DLL)中，PHP是與Web服務器一起啟動并運行的。（是apache在CGI的基礎上進行的一種擴展，加快PHP的運行效率）

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

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
三者后兩者性能可能稍優，但是Apache由于有豐富的模塊和功能，目前來說仍舊是老大。有人測試nginx+PHP-FPM在高并發情況下可能會達到Apache+mod_php5的5~10倍，現在nginx+PHP-FPM使用的人越來越多。

分享：基于HBase Thrift接口的一些使用問題及相關注意事項的詳解
本篇文章是對HBase Thrift接口的一些使用問題及相關注意事項進行了詳細的分析介紹，需要的朋友參考下