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

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

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

我自問自答好了。

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

php 的 sapi 有 cgi/cli/mod_php/fast-cgi/isapi
一個(gè) php 進(jìn)行將會(huì)粗略的經(jīng)歷以下 4 步：

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

可以看出對于 php 服務(wù)來說，只有 2 和 3 兩步會(huì)因?yàn)檎埱蟮牟煌鲆恍┎煌奶幚恚? 和 4 則是相同的，直到你下一次修改配置。

但需要理解的是：

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

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

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

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

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