FastCGI與PHP-FPM

要想弄清FastCGI和PHP-FPM，就須要先弄清一些基本的概念: CGI FastCGI PHP-FPM PHP-CGI。

CGI

通用網關接口，描述的服務器和請求處理程序之間的數據傳輸的一種標準。

這能夠簡單的理解爲CGI就是保證web server傳過來的數據是標準的，可以方便的請求處理程序的編寫。

在這一層面之上，web server只是請求內容的分發者。好比，若是請求index.html，那麼web server會去文件系統中查找這個文件，而後發送到瀏覽器，那麼這裏分發的就是靜態資源。若是這個時候請求的不是index.html而是index.php的話，根據web server(好比nginx)的配置文件，server判斷出這次請求的不是靜態文件，而是一個PHP的程序，須要去找PHP解析器來處理，那麼server會簡單處理這個請求後交給PHP解析器。Nginx會將請求的URL、GET/POST數據、HTTP Header等協議規定好的數據傳遞處處理請求的CGI程序中。

讓咱們在具體一點的分析。當server收到index.php這個請求後，server會啓動對應的CGI程序，本文中指的就是PHP的解析器。接下來PHP解析器會解析配置文件php.ini，初始化運行環境，而後處理請求，最後按照CGI規定的數據格式返回處理結果，同時退出當前的CGI程序的進程。server將CGI程序的結果返回到瀏覽器中。

說了這麼多，重點就是CGI是一個相互通訊的協議，是一種雙方約定好的標準。

FastCGI

在上面的CGI中，咱們能夠看到，當請求來臨的時候CGI會初始化運行環境，而後處理請求，標準的CGI會對每個請求都執行這些操做，因此每次的處理時間會很長，畢竟頻繁的啓動進程會消耗大量的資源。

FastCGI就是爲了解決這種缺陷而出現的。FastCGI是CGI的加強版，爲了減小web server與CGI程序之間的互動開銷，從而使server可以同時處理更多的請求。

那麼FastCGI是如何作到的呢？首先，FastCGI會先啓動一個master進程，解析配置文件，初始化運行環境，而後在啓動多個worker進程。當請求來臨時，server將請求傳遞到master，master將請求傳遞給一個已經啓動了的worker，而後就能夠接收下一個請求；worker處理完請求即可以直接將處理的標準輸出和錯誤信息返回到server。這樣就避免了每次處理請求時都須要作的forkCGI進程的工做。當請求太多，worker不夠用的時候，master能夠根據配置文件預先啓動多個worker等着；當worker空閒太多時，也會停掉一些。大多數的FastCGI實現都會維護一個進程池(swoole做爲HttpServer時，就是相似這樣的工做方式)。

到如今咱們瞭解了CGI和FastCGI：

因爲CGI處理每個請求都須要fork新的進程，效率底下，就出現了CGI的加強版FastCGI，FastCGI維護一個本身的進程池來避免fork新進程的開銷，從而大大的提升了性能。

PHP-CGI、PHP-FPM

PHP-CGI是PHP自帶的FastCGI管理器，然而他卻存在着比較嚴重的問題：

1. PHP-CGI變動php.ini配置後需重啓PHP-CGI才能讓新的php-ini生效，不能夠平滑重啓.
2. 直接殺死PHP-CGI進程，PHP就不能運行了。(PHP-FPM就沒有這個問題,守護進程會平滑重新生成新的子進程。）

針對上面的兩個問題，PHP-FPM便應運而生。PHP-FPM提供了更好的PHP進程管理方式，能夠有效控制內存和進程、能夠平滑重載PHP配置。因爲PHP-FPM的優異表現，PHP官方在PHP5.3.3中集成PHP-FPM，使得PHP-FPM愈來愈受歡迎。