CGI
CGI全稱是“公共網關接口”(Common Gateway Interface)，HTTP伺服器與你的或其它機器上的程式進行“交談”的一種工具，其程式須運作在網絡伺服器上。
FastCGI
FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行着，隻要激活後，不會每次都要花費時間去fork一次（這是CGI最為人诟病的fork-and-execute 模式）。它還支援分布式的運算，即 FastCGI 程式可以在網站伺服器以外的主機上執行并且接受來自其它網站伺服器來的請求。
FastCGI是語言無關的、可伸縮架構的CGI開放擴充，其主要行為是将CGI解釋器程序保持在記憶體中并是以獲得較高的性能。衆所周知，CGI解釋器的反複加載是CGI性能低下的主要原因，如果CGI解釋器保持在記憶體中并接受FastCGI程序管理器排程，則可以提供良好的性能、伸縮性、Fail- Over特性等等。
FastCGI也可以稱為是一種協定标準，比如下面要說的php-fpm就是支援解析php的一個fastCGI程序管理器/引擎。
FastCGI的工作原理
- Web Server啟動時載入FastCGI程序管理器（IIS ISAPI或Apache Module)
- FastCGI程序管理器自身初始化，啟動多個CGI解釋器程序(可見多個php-cgi)并等待來自Web Server的連接配接。
- 當用戶端請求到達Web Server時，FastCGI程序管理器選擇并連接配接到一個CGI解釋器。Web server将CGI環境變量和标準輸入發送到FastCGI子程序php-cgi。
- FastCGI子程序完成處理後将标準輸出和錯誤資訊從同一連接配接傳回Web Server。當FastCGI子程序關閉連接配接時，請求便告處理完成。FastCGI子程序接着等待并處理來自FastCGI程序管理器(運作在Web Server中)的下一個連接配接。 在CGI模式中，php-cgi在此便退出了。
在上述情況中，你可以想象CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部擴充并重初始化全部資料結構。使用FastCGI，所有這些都隻在程序啟動時發生一次。一個額外的好處是，持續資料庫連接配接(Persistent database connection)可以工作。
FastCGI的不足
因為是多程序，是以比CGI多線程消耗更多的伺服器記憶體，PHP-CGI解釋器每程序消耗7至25兆記憶體，将這個數字乘以50或100就是很大的記憶體數。
Nginx 0.8.46+PHP 5.2.14(FastCGI)伺服器在3萬并發連接配接下，開啟的10個Nginx程序消耗150M記憶體（15M*10=150M），開啟的64個php-cgi程序消耗1280M記憶體（20M*64=1280M），加上系統自身消耗的記憶體，總共消耗不到2GB記憶體。如果伺服器記憶體較小，完全可以隻開啟25個php-cgi程序，這樣php-cgi消耗的總記憶體數才500M。
上面的資料摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建勝過Apache十倍的Web伺服器(第6版)
PHP-CGI
PHP-CGI是PHP自帶的FastCGI管理器。
PHP-CGI的不足：
- php-cgi變更php.ini配置後需重新開機php-cgi才能讓新的php-ini生效，不可以平滑重新開機。
- 直接殺死php-cgi程序，php就不能運作了。(PHP-FPM和Spawn-FCGI就沒有這個問題，守護程序會平滑從新生成新的子程序。）
總結：
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是個協定，跟程序什麼的沒關系。那fastcgi又是什麼呢？Fastcgi是用來提高CGI程式性能的。
提高性能，那麼CGI程式的性能問題在哪呢？”PHP解析器會解析php.ini檔案，初始化執行環境”，就是這裡了。标準的CGI對每個請求都會執行這些步驟（不閑累啊！啟動程序很累的說！），是以處理每個時間的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼做的呢？首先，Fastcgi會先啟一個master，解析配置檔案，初始化執行環境，然後再啟動多個worker。當請求過來時，master會傳遞給一個worker，然後立即可以接受下一個請求。這樣就避免了重複的勞動，效率自然是高。而且當worker不夠用時，master可以根據配置預先啟動幾個worker等着；當然空閑worker太多時，也會停掉一些，這樣就提高了性能，也節約了資源。這就是fastcgi的對程序的管理。
那PHP-FPM又是什麼呢？是一個實作了Fastcgi的程式，被PHP官方收了。
大家都知道，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核心裡面，要使用這個功能，需要找到與源碼版本相同的php-fpm對核心打更新檔，然後再編譯。
後來PHP核心內建了PHP-FPM之後就友善多了，使用–enalbe-fpm這個編譯參數即可。
有的說，修改了php.ini配置檔案後，沒辦法 平滑重新開機，是以就誕生了php-fpm
是的，修改php.ini之後，php-cgi程序的确是沒辦法平滑重新開機的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就可以歇着了，通過這種機制來平滑過度。
還有的說PHP-CGI是PHP自帶的FastCGI管理器，那這樣的話幹嗎又弄個php-fpm出
不對。php-cgi隻是解釋PHP腳本的程式而已。
FastCGI像是一個常駐(long-live)型的CGI，是用來提高CGI程式性能的。CGI是通用網關接口，是外部應用程式與Web伺服器之間的接口标準，CGI是為了保證web server傳遞過來的資料是标準格式的，友善CGI程式的編寫者。如果請求的是靜态資料/index.html，那麼web server會去檔案系統找到這個檔案發送給浏覽器。如果請求的是動态資料/index.php，nginx需要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些資料給PHP解析器呢？url要有吧，查詢字元串要有吧，POST資料也要有吧，HTTP header不能少吧，好的，CGI就是規定要傳哪些資料、以什麼樣的格式傳遞給後方處理這個請求的協定。
那麼CGI程式的性能問題在哪呢？PHP解析器會解析php.ini檔案，初始化執行環境，就是這裡了。标準的CGI對每個請求都會執行這些步驟（不閑累啊！啟動程序很累的說！），是以處理的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼做的呢？
首先，Fastcgi會先啟一個master，解析配置檔案，初始化執行環境，
然後再啟動多個worker。當請求過來時，master會傳遞給一個worker，
然後立即可以接受下一個請求。這樣就避免了重複的勞動，效率自然是高。
而且當worker不夠用時，master可以根據配置預先啟動幾個worker等着；
當然空閑worker太多時，也會停掉一些，這樣就提高了性能，也節約了資源。這就是fastcgi的對程序的管理。
最後來個形象的比喻：
你(PHP)去和愛斯基摩人(web伺服器，如 Apache、Nginx)談生意，你說中文(PHP代碼)，他說愛斯基摩語(C代碼)，互相聽不懂，怎麼辦？那就都把各自說的話轉換成英語(FastCGI 協定)吧。怎麼轉換呢？你就要使用一個翻譯機(PHP-FPM) (當然對方也有一個翻譯機，那個是他自帶的)。我們這個翻譯機是最新型的，老式的那個（PHP-CGI）被淘汰了。不過它(PHP-FPM)隻有年輕人（Linux系統）會用，老頭子們（Windows系統）不會擺弄它，隻好繼續用老式的那個。