PHP CGI FastCGI php-fpm HHVM

web服務器接受到瀏覽器的請求時，若是是靜態資源如 html 文件就直接將其返回給瀏覽器；若是是 php、asp 這樣的動態資源，服務器本身不能處理，就要外包給別人處理，具體實現就須要CGI （common gateway interface）約定，cgi能夠理解爲一種協議or一類處理程序，能夠用 vb，c，php， python 實現。

WEB 與 CGI 交互

CGI（Common Gateway Interface）是1993年由美國國家超級電腦應用中心（NCSA）爲 NCSA HTTPd Web 服務器開發的。這個 Web 服務器使用了 UNIX shell 環境變量 來保存從 Web 服務器傳遞出去的參數，而後生成一個運行 CGI 的獨立進程。CGI的第一個實現是 Perl 寫的，可是 CGI 有以下問題：

• 效率低下：每個鏈接 fork 一個進程處理。
• 功能十分有限：CGI只能收到一個請求，輸出一個響應。

因此就有了Apache的mod_php，FastCGI（Fast Common Gateway Interface）

FastCGI使用進程/線程池來處理一連串的請求。這些進程/線程由FastCGI服務器管理，而不是Web服務器。 當進來一個請求時，Web服務器把環境變量和這個頁面請求經過一個Socket長鏈接傳遞給FastCGI進程。因此FastCGI有以下的優勢：

• 性能：經過進程/線程池規避了CGI開闢新的進程的開銷。
• 兼容：很是容易改造現有CGI標準的程序。
• 語言無關：FastCGI是一套標準，理論上講只要能進行標準輸出（stdout）的語言均可以做爲FastCGI標準的Web後端。

Web Server隔離：FastCGI後端和Web Server運行在不一樣的進程中，後端的任何故障不會致使Web Server掛掉。

專利：沒有Apache mod_php之類的私有API的知識產權問題。

擴展：FastCGI後端和Web Server經過Socket進行通訊，二者能夠分佈式部署並方便進行橫向擴展。

HHVM

HHVM 是 Facebook 開發的高性能 PHP 虛擬機，宣稱比官方的快9倍。

在討論 HHVM 實現原理前，咱們先設身處地想一想：假設你有個 PHP 寫的網站遇到了性能問題，經分析後發現很大一部分資源就耗在 PHP 上，這時你會怎麼優化 PHP 性能？

好比能夠有如下幾種方式：

• 方案1，遷移到性能更好的語言上，如 Java、C++、Go。
• 方案2，經過 RPC 將功能分離出來用其它語言實現，讓 PHP 作更少的事情，好比 Twitter 就將大量業務邏輯放到了 Scala 中，前端的 Rails 只負責展示。
• 方案3，寫 PHP 擴展，在性能瓶頸地方換 C/C++。
• 方案4，優化 PHP 的性能。

方案1幾乎不可行，十年前 Joel 就拿 Netscape 的例子警告過，你將放棄是多年的經驗積累，尤爲是像 Facebook 這種業務邏輯複雜的產品，PHP 代碼實在太多了，據稱有2千萬行（引用自 [PHP on the Metal with HHVM]），修改起來的成本恐怕比寫個虛擬機還大，並且對於一個上千人的團隊，從頭開始學習也是不可接受的。

方案2是最保險的方案，能夠逐步遷移，事實上 Facebook 也在朝這方面努力了，並且還開發了 Thrift 這樣的 RPC 解決方案，Facebook 內部主要使用的另外一個語言是 C++，從早期的 Thrift 代碼就能看出來，由於其它語言的實現都很簡陋，無法在生產環境下使用。

目前在 Facebook 中據稱 PHP:C++ 已經從 9:1 增長到 7:3 了，加上有 Andrei Alexandrescu 的存在，C++ 在 Facebook 中愈來愈流行，但這隻能解決部分問題，畢竟 C++ 開發成本比 PHP 高得多，不適合用在常常修改的地方，並且太多 RPC 的調用也會嚴重影響性能。

方案3看起來美好，實際執行起來卻很難，通常來講性能瓶頸並不會很顯著，大可能是不斷累加的結果，加上 PHP 擴展開發成本高，這種方案通常只用在公共且變化不大的基礎庫上，因此這種方案解決不了多少問題。

能夠看到，前面3個方案並不能很好地解決問題，因此 Facebook 其實沒有選擇的餘地，只能去考慮 PHP 自己的優化了。

http://wuduoyi.com/note/hhvm/