PHP-FPM 進化史

最近有幸讀到一篇文章，一文將CGI 的進化史講的特別詳細，雖然我本身以前也整理過 CGI、FastCGI、PHP-FPM 相關的筆記，可是並無從原理的角度來認識 CGI。

CGI 的誕生

早些年的Web 應用很簡單，客戶端經過瀏覽器發起請求，服務端直接返回響應。

隨着互聯網的發展，簡單的Web 應用已經不能知足開發者們了。
咱們但願Web服務器有更多的功能，飛速發展的同時還能讓不一樣語言的開發者也能加入。

CGI協議協議的誕生就是 Web服務器和其餘領域的開發者在保證遵照協議的基礎上，剩下的能夠自由發揮，而實現這個協議的腳本叫作CGI 程序。

CGI協議規定了須要向CGI腳本設置的環境變量和一些其餘信息，CGI程序完成某一個功能，能夠用PHP，Python，Shell或者C語言編寫。

在沒有CGI 以前，其餘語言若是須要接入Mysql 或者Memcache，還須要使用C 語言，但有了CGI協議，咱們的Web處理流程能夠變成下圖這樣：

FastCGI 的誕生

CGI程序存在致命的缺點：每當客戶端發起請求，服務器將請求轉發給CGI，WEB 服務器就請求操做系統生成一個新的CGI解釋器進程(如php-cgi），CGI進程則處理完一個請求後退出，下一個請求來時再建立新進程。

咱們知道，執行一個PHP程序的必需要先解析php.ini文件，而後模塊初始化等等一系列工做，每次都反覆這樣很是浪費資源。

FastCGI協議在CGI協議的基礎上，作出了以下改變：

1. FastCGI被設計用來支持常駐（long-lived）應用進程，減小了fork-and-execute帶來的開銷
2. FastCGI進程經過監聽的socket，收來自Web服務器的鏈接，這樣FastCGI 進程能夠獨立部署
3. 服務器和FastCGI監聽的socket 之間按照消息的形式發送環境變量和其餘數據

咱們稱實現了FastCGI協議的程序爲FastCGI程序，FastCGI程序的交互方式以下圖所示：

PHP-FPM 的誕生

FastCGI 程序當然已經很好了，但咱們的需求老是有點苛刻，它仍是存在一些明顯缺點的：

1. 當咱們更改配置文件(php.ini)後，php-cgi（FastCGI 程序） 沒法平滑重啓
2. 咱們fork的進程個數和請求量正比，請求繁忙時 fork 進程多，動態調整 php-cgi還沒作到

上面說起php-cgi 實現的FastCGI問題官方沒有解決，幸運的是有第三方幫咱們解決了，它就是 php-fpm。

它能夠獨立運行，不依賴php-cgi，換句話說，它本身實現了FastCGI協議而且支持進程平滑重啓且帶進程管理功能。

參考連接

• 從CGI到FastCGI到PHP-FPM