apache php_mod 和 php-fpm fast-cgi 的處理php請求時初始化執(zhí)行環(huán)境的區(qū)別

http://fastjoomlahost.com/mod...

我覺得這篇文章可以參考下，mod_php的作用是可以把php嵌入到apache，這樣apache能直接運行php程序，不需要單獨開一個php進程，理論上會比php-fpm資源占用更小。

我自問自答好了。

最近一段時間查閱了 php 內部執(zhí)行流程的相關資料，可以明確的理解此問題了。

php 的 sapi 有 cgi/cli/mod_php/fast-cgi/isapi
一個 php 進行將會粗略的經歷以下 4 步：

1、minit 模塊初始化：啟動 php 進程（解釋器，zend 引擎），讀取 php.ini，加載并初始化相關擴展和模塊，redis.so 等
2、rinit 請求初始化：處理請求信息，比如： GET index.php HTTP1.1/ php cli_index.php。處理好請求信息后便會載入相應的業(yè)務源碼，并準備開始執(zhí)行
=====================================執(zhí)行業(yè)務=============================================
3、rshutdown 關閉請求：返回處理狀態(tài)和相關結果數(shù)據(jù)給請服務器，服務器返回給客戶端，清理內存，釋放資源
4、mshutdown 關閉模塊：關閉相關擴展和模塊，關閉 php 進程（解釋器，zend 引擎）

可以看出對于 php 服務來說，只有 2 和 3 兩步會因為請求的不同而做一些不同的處理，1 和 4 則是相同的，直到你下一次修改配置。

但需要理解的是：

cgi/cli 是以 1，2，3，4 的步驟去執(zhí)行，每次執(zhí)行都會進行這四部。

mod_php/fast-cig/ispai 則是在啟動進程時執(zhí)行 1，然后等待請求。請求到達時執(zhí)行 2 和 3 ，但并不會繼續(xù)執(zhí)行 4 ，除非進程被回收。這也是為什么 mod_php/fast-cgi 模式效率要高于 cgi 模式，1 / 4 兩步本身就是可重復利用的。

mod_php 并不是敗給了 php-fpm，而是敗給了 nginx + php-fpm。單純的比較一個 mod_php 進程的執(zhí)行效率可能并不比 php-fpm 的 fast-cgi 進程慢，甚至速度還要快一些，所以 apache 是因為自己的 IO 模型而失勢在響應速度階段，處理速度并不比 php-fpm 慢，但面向請求來講處理時間 = 響應時間 + 處理 + 響應結束 整個過程，所以 apache 還是慢了下來。但 apache 的 進程模型 和 IO 模型導致了它沒辦法靈活快速的響應突發(fā)的高并發(fā)和高并發(fā)所帶來的巨大流量，而這卻是 nginx 的特性。

所以在 mod_php 或 fast-cgi 啟動時，php 引擎也同時完成了相關初始化工作，讀取配置并載入相關擴展和模塊。然后等待請求，請求到來時進行請求初始化，分析請求，載入我們的腳本，處理數(shù)據(jù)，返回數(shù)據(jù)，清理本次請求的數(shù)據(jù)和資源，但并不會關閉 php 引擎，會繼續(xù)回到等待請求的哪一步。

根據(jù)實際測試，發(fā)現(xiàn)還是event的性能要比prefork來得好，相同請求下event的資源消耗比prefork少%20以上。