fastcgi與php fpm的關係

剛開始對這個問題我也挺糾結的，看了《http權威指南》後，感覺清晰了不少。

首先，cgi是幹嘛的？cgi是為了保證web server傳遞過來的資料是標準格式的，方便cgi程式的編寫者。

web server（比如說nginx）只是內容的分發者。比如，如果請求/index.html，那麼web server會去檔案系統中找到這個檔案，傳送給瀏覽器，這裡分發的是靜態資料。好了，如果現在請求的是/index.php，根據配置檔案，nginx知道這個不是靜態檔案，需要去找php解析器來處理，那麼他會把這個請求簡單處理後交給php解析器。nginx會傳哪些資料給php解析器呢？url要有吧，查詢字串也得有吧，post資料也要有，http header不能少吧，好的，cgi就是規定要傳哪些資料、以什麼樣的格式傳遞給後方處理這個請求的協議。仔細想想，你在php**中使用的使用者從**來的。

當web server收到/index.php這個請求後，會啟動對應的cgi程式，這裡就是php的解析器。接下來php解析器會解析php.ini檔案，初始化執行環境，然後處理請求，再以規定cgi規定的格式返回處理後的結果，退出程序。web server再把結果返回給瀏覽器。

提高效能，那麼cgi程式的效能問題在哪呢？"php解析器會解析php.ini檔案，初始化執行環境"，就是這裡了。標準的cgi對每個請求都會執行這些步驟（不閒累啊！啟動程序很累的說！），所以處理每個時間的時間會比較長。這明顯不合理嘛！那麼fastcgi是怎麼做的呢？首先，fastcgi會先啟乙個master，解析配置檔案，初始化執行環境，然後再啟動多個worker。當請求過來時，master會傳遞給乙個worker，然後立即可以接受下乙個請求。這樣就避免了重複的勞動，效率自然是高。而且當worker不夠用時，master可以根據配置預先啟動幾個worker等著；當然空閒worker太多時，也會停掉一些，這樣就提高了效能，也節約了資源。這就是fastcgi的對程序的管理。

大家都知道，php的直譯器是php-cgi。php-cgi只是個cgi程式，他自己本身只能解析請求，返回結果，不會程序管理（皇上，臣妾真的做不到啊！）所以就出現了一些能夠排程php-cgi程序的程式，比如說由lighthttpd分離出來的spawn-fcgi。好了php-fpm也是這麼個東東，在長時間的發展後，逐漸得到了大家的認可（要知道，前幾年大家可是抱怨php-fpm穩定性太差的），也越來越流行。

網上有的說，fastcgi是乙個協議，php-fpm實現了這個協議

對。

對。php-fpm的管理物件是php-cgi。但不能說php-fpm是fastcgi程序的管理器，因為前面說了fastcgi是個協議，似乎沒有這麼個程序存在，就算存在php-fpm也管理不了他（至少目前是）。 有的說，php-fpm是php核心的乙個補丁

以前是對的。因為最開始的時候php-fpm沒有包含在php核心裡面，要使用這個功能，需要找到與原始碼版本相同的php-fpm對核心打補丁，然後再編譯。後來php核心整合了php-fpm之後就方便多了，使用--enalbe-fpm這個編譯引數即可。

是的，修改php.ini之後，php-cgi程序的確是沒辦法平滑重啟的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就可以歇著了，通過這種機制來平滑過度。

FastCgi與PHP fpm之間的關係

我在網上查fastcgi與php fpm的關係，查了快一周了，基本看了個遍，真是眾說紛紜，沒乙個權威性的定義。網上有的說，fastcgi是乙個協議，php fpm實現了這個協議 有的說，php fpm是fastcgi程序的管理器，用來管理fastcgi程序的 有的說，php fpm是php核心的乙個...

FastCgi 與 PHP FPM 之間的區別

cgi 是為了保證 web server 傳遞過來的資料是標準格式的，方便 cgi 程式的編寫者。web server 比如說 nginx 只是內容的分發者。當 web server 收到 index.php這個請求後，會啟動對應的 cgi 程式，這裡就是 php 的解析器。接下來 php 解析器會...

FastCgi 與 PHP FPM 之間的區別

cgi 是為了保證 web server 傳遞過來的資料是標準格式的，方便 cgi 程式的編寫者。web server 比如說 nginx 只是內容的分發者。當 web server 收到 index.php這個請求後，會啟動對應的 cgi 程式，這裡就是 php 的解析器。接下來 php 解析器會...