php安裝模式mod_php和Fastcgi的選擇與對比

安裝php又面臨到了模式的選擇，之前都是選擇mod_php模式，由於這樣安裝比較方便哈，今天忽然關心起FastCGI這種模式，敗毒了一把，找到了一些關於mod_php和Fastcgi的選擇與對比這方面的討論，如今發出來留一個記號，以便進一步研究：

第一篇：php在apache中安裝模式的區別：fastcgi和mod_php

     說到fastCgi就不得不說Cgi。
     CGI英文全稱是 Common Gateway Interface，一般翻譯爲共同網關接口，是HTTP服務器與機器上的其餘程序進行通訊的一個接口。這個「其餘程序」可使用任何計算機語言來編寫，它經過CGI這個接口從HTTP服務器取得輸入，而後把運行的結果又經過CGI這個接口交給HTTP服務器，而HTTP服務器把這個結果送給瀏覽器。

     CGI的出現讓WEB從靜態變爲爲動態，隨着Web的愈來愈普及，不少的網站的都須要有動態的頁面，以便與瀏覽者互交。CGI方式的缺點也愈來愈突出。由於HTTP要生成一個動態頁面，系統就必須啓動一個新的進程以運行CGI程序，不斷地fork是一項很消耗時間和資源的工做。這就出現了FastCGI。

   百度百科關於FastCGI

2. FastCGI 可在任何平臺上使用，Netscape Enterprise 及 IIS 都有 FastCGI 的模塊可供使用，阿帕契 (Apache，以及利用 Apache 衍生出作的服務器) 上也有 mod_fastcgi 可用。
3. FastCGI 支持 C/C++，Ruby, Perl，Tcl，Java，Python 等程序語言。
4. FastCGI 的應用程序亦兼容於 CGI。即 FastCGI 的應用程序也能夠當成 CGI 來執行。
5. 現有的 CGI 程序要改寫成 FastCGI 很是簡單，最少可能只須要多加入三行程序代碼。
6. FastCGI 的偵錯方式與 CGI 大同小異，只要帶入程序所需的環境變量及參數，便可在命令列模式執行或偵錯。
7. FastCGI 應用程序的寫做方式與 CGI 相似，除了幾項原則要特別注意外，FastCGI 的寫做方式跟 CGI 幾乎同樣，與學習 Web Server API 比較起來， FastCGI 簡單多了。
8. FastCGI 支授分佈式運算 (distributed computing)，即 FastCGI 程序能夠在網站服務器之外的主機上執行而且接受來自其它網站服務器來的請求。

     mod_php就是把PHP作爲APACHE一個內置模塊。讓apache http服務器自己可以支持PHP語言，不須要每個請求就啓動PHP解釋器來解釋PHP。

第二篇：mod_php or fastcgi性能比較與選擇

用php確定少了不這個問題的選擇，cgi天然就沒必要說了，可是mod_php和fastcgi的爭論確仍是比較多的。
找了一些資料，晾在這，可供參考。
首先，性能應該是你們最關心的問題了，除了mod_php和fastcgi 的 benchmark，還有一些服務器差異的測試，如apache vs lighthttpd

1 mod_php, LightTPD, FastCGI - What’s fastest?
     這個bechmark的結果是 Apache(prefork)+Fastcgi+php的性能是最好的。超過了apache+mod_php，甚至也超過了lightty+fastcgi+php。固然，這個結果得出值相差都很小。另外，以上說的幾個結果都使用了APC加速，使用APC後性能提升1倍以上。

2 php4-mod-vs-cgi
   這個bechmark是在php4的環境下完成的。其summary.txt的內容以下。

------------------------

PHP4 module, very simple script (phpinfo.php): requests/s
plain 130.04
+turckcache 129.42
+turckcache+zend-optimizer 125.50

PHP4 module, very complex script (insurance application): requests/s
plain 1.84
+turckcache 6.23
+turckcache+zend-optimizer 5.58
+optimizer 1.58

PHP4 CGI, very simple script (phpinfo.php): requests/s
plain 22.69
+turckcache n/a*
+turckcache+zend-optimizer n/a*
+optimizer 21.23

PHP4 CGI, very complex script (insurance application): requests/s
plain 2.00
+turckcache n/a*
+turckcache+zend-optimizer n/a*
+optimizer 1.72

* = turkcache doesn't support caching of the PHP scripts in CGI mode

上面的結果我以爲須要關注的是無cache的狀況，由於使用mod_php或fastcgi主要仍是用來生成動態頁面。前面的cache有更好的工具來實現，如squid。因此，這個結果也是fastcgi勝出，相差也不大。

3 http://buytaert.net/drupal-performance?page=1
   這個文章的結果和上面兩個恰好相反。使用fastcgi代替mod_php後，」When switching from

to

we observe a 63% slowdown for anonymous visitors, and a 18% slowdown for authenticated visitors.」如下是圖表

另外，benchmark中也作了和lightty的比較，以下圖：

這個文章的結論是Apache+mod_php性能好於Apache+fastcgi。另外，Apache+mod_php略好於lightty+fastcgi。

4 最後看看 fastcgi官方本身怎麼說的吧
    Of course, the answer is that it depends upon the application. A more complete answer is that FastCGI often wins by a significant margin, and seldom loses by very much.

5 結論是，仍是根據本身的應用測一下吧….

最後,我的觀點
若是mod_php和fastcgi的性能相差不是很大的話，仍是傾向於fastcgi的，這種方式畢竟更靈活、安全和簡單。
1 使用fastcgi，你的web server 能夠比較簡單的切換，能夠測試不一樣的服務器，Apache,lightty,ngix 等等，不須要有代碼的修改
2 若是想換腳本的實現，如不用php，而是改爲perl,python之類的，web服務器也不須要任何的改動
3 web server和fastcgi能夠用不一樣的賬號運行，帶來了必定的安全隔離
4 只在Apache中編個mod_fastcgi能夠說是簡單多了，把mod_php編進apache時，出問題時很難定位是php的問題仍是apache的問題，我就見過這樣的core，函數調用幾十層，一點頭緒都沒有

原文連接： http://blog.csdn.net/21aspnet/article/details/3280512