牛人寫的facebook優化php來龍去脈

文藝小青年發表於2017-07-07
優化PHP

背景

HHVM 是 Facebook 開發的高效能 PHP 虛擬機器，宣稱比官方的快9倍，我很好奇，於是抽空簡單瞭解了一下，並整理出這篇文章，希望能回答清楚兩方面的問題：

  • HHVM 到底靠譜麼？是否可以用到產品中？
  • 它為什麼比官方的 PHP 快很多？到底是如何優化的？

你會怎麼做？

在討論 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 本身的優化了。

更快的 PHP

既然要優化 PHP，那如何去優化呢？在我看來可以有以下幾種方法：

  • 方案1，PHP 語言層面的優化。
  • 方案2，優化 PHP 的官方實現（也就是 Zend）。
  • 方案3，將 PHP 編譯成其它語言的 bytecode（位元組碼），藉助其它語言的虛擬機器（如 JVM）來執行。
  • 方案4，將 PHP 轉成 C/C++，然後編譯成原生程式碼。
  • 方案5，開發更快的 PHP 虛擬機器。

PHP 語言層面的優化是最簡單可行的，Facebook 當然想到了，而且還開發了 XHProf 這樣的效能分析工具，對於定位效能瓶頸是很有幫助的。

不過 XHProf 還是沒能很好解決 Facebook 的問題，所以我們繼續看，接下來是方案2，簡單來看，Zend 的執行過程可以分為兩部分：將 PHP 編譯為 opcode、執行 opcode，所以優化 Zend 可以從這兩方面來考慮。

優化 opcode 是一種常見的做法，可以避免重複解析 PHP，而且還能做一些靜態的編譯優化，比如 Zend Optimizer Plus，但由於 PHP 語言的動態性，這種優化方法是有侷限性的，樂觀估計也只能提升20%的效能。另一種考慮是優化 opcode 架構本身，如基於暫存器的方式，但這種做法修改起來工作量太大，效能提升也不會特別明顯（可能30%？），所以投入產出比不高。

另一個方法是優化 opcode 的執行，首先簡單提一下 Zend 是如何執行的，Zend 的 interpreter（也叫直譯器）在讀到 opcode 後，會根據不同的 opcode 呼叫不同函式（其實有些是 switch，不過為了描述方便我簡化了），然後在這個函式中執行各種語言相關的操作（感興趣的話可看看深入理解 PHP 核心這本書），所以 Zend 中並沒有什麼複雜封裝和間接呼叫，作為一個直譯器來說已經做得很好了。

想要提升 Zend 的執行效能，就需要對程式的底層執行有所解，比如函式呼叫其實是有開銷的，所以能通過 Inline threading 來優化掉，它的原理就像 C 語言中的 inline 關鍵字那樣，但它是在執行時將相關的函式展開，然後依次執行（只是打個比方，實際實現不太一樣），同時還避免了 CPU 流水線預測失敗導致的浪費。

另外還可以像 JavaScriptCore 和 LuaJIT 那樣使用匯編來實現 interpreter，具體細節建議看看 Mike 的解釋

但這兩種做法修改代價太大，甚至比重寫一個還難，尤其是要保證向下相容，後面提到 PHP 的特點時你就知道了。

開發一個高效能的虛擬機器不是件簡單的事情，JVM 花了10多年才達到現在的效能，那是否能直接利用這些高效能的虛擬機器來優化 PHP 的效能呢？這就是方案3的思路。

其實這種方案早就有人嘗試過了，比如 Quercus 和 IBM 的 P8，Quercus 幾乎沒見有人使用，而 P8 也已經死掉了。Facebook 也曾經調研過這種方式，甚至還出現過不靠譜的傳聞 ，但其實 Facebook 在2011年就放棄了。

因為方案3看起來美好，但實際效果卻不理想，按照很多大牛的說法（比如 Mike），VM 總是為某個語言優化的，其它語言在上面實現會遇到很多瓶頸，比如動態的方法呼叫，關於這點在 Dart 的文件中有過介紹，而且據說 Quercus 的效能與 Zend+APC 比差不了太多（[來自The HipHop Compiler for PHP]），所以沒太大意義。

不過 OpenJDK 這幾年也在努力，最近的 Grall 專案看起來還不錯，也有語言在上面取得了顯著的效果，但我還沒空研究 Grall，所以這裡無法判斷。

接下來是方案4，它正是 HPHPc（HHVM 的前身）的做法，原理是將 PHP 程式碼轉成 C++，然後編譯為本地檔案，可以認為是一種 AOT（ahead of time）的方式，關於其中程式碼轉換的技術細節可以參考 The HipHop Compiler for PHP 這篇論文，以下是該論文中的一個截圖，可以通過它來大概瞭解：

這種做法的最大優點是實現簡單（相對於一個 VM 來說），而且能做很多編譯優化（因為是離線的，慢點也沒事），比如上面的例子就將- 1優化掉了，但它很難支援 PHP 中的很多動態的方法，如 eval()、create_function()，因為這就得再內嵌一個 interpreter，成本不小，所以 HPHPc 乾脆就直接不支援這些語法。

除了 HPHPc，還有兩個類似的專案，一個是 Roadsend，另一個是 phc ，phc 的做法是將 PHP 轉成了 C 再編譯，以下是它將 file_get_contents($f) 轉成 C 程式碼的例子：

static php_fcall_info fgc_info;
php_fcall_info_init ("file_get_contents", &fgc_info);
php_hash_find (LOCAL_ST, "f", 5863275, &fgc_info.params);
php_call_function (&fgc_info);

話說 phc 作者曾經在部落格上哭訴，說他兩年前就去 Facebook 演示過 phc 了，還和那裡的工程師交流過，結果人家一發布就火了，而自己忙活了4年卻默默無聞，現在前途渺茫。。。

Roadsend 也已經不維護了，對於 PHP 這樣的動態語言來說，這種做法有很多的侷限性，由於無法動態 include，Facebook 將所有檔案都編譯到了一起，上線時的檔案部署居然達到了 1G，越來越不可接受了。

另外有還有一個叫 PHP QB 的專案，由於時間關係我沒有看，感覺可能是類似的東東。

所以就只剩下一條路了，那就是寫一個更快的 PHP 虛擬機器，將一條黑路走到底，或許你和我一樣，一開始聽到 Facebook 要做一個虛擬機器是覺得太離譜，但如果仔細分析就會發現其實也只有這樣了。

更快的虛擬機器

HHVM 為什麼更快？在各種新聞報導中都提到了 JIT 這個關鍵技術，但其實遠沒有那麼簡單，JIT 不是什麼神奇的魔法棒，用它輕輕一揮就能提升效能，而且 JIT 這個操作本身也是會耗時的，對於簡單的程式沒準還比 interpreter 慢，最極端的例子是 LuaJIT 2 的 Interpreter 就稍微比 V8 的 JIT 快，所以並不存在絕對的事情，更多還是在細節問題的處理上，HHVM 的發展歷史就是不斷優化的歷史，你可以從下圖看到它是如何一點點超過 HPHPc 的：

值得一提的是在 Android 4.4 中新的虛擬機器 ART 就採用的是 AOT 方案（還記得麼？前面提到的 HPHPc 就是這種），結果比之前使用 JIT 的 Dalvik 快了一倍，所以說 JIT 也不一定比 AOT 快。

因此這個專案是有很大風險的，如果沒有強大的內心和毅力，極有可能半途而廢，Google 就曾經想用 JIT 提升 Python 的效能，但最終失敗了，對於 Google 來說用到 Python 的地方其實並沒什麼效能問題（好吧，以前 Google 是用 Python 寫過 crawl [參考 In The Plex]，但那都是1996年的事情了）。

比起 Google，Facebook 顯然有更大的動力和決心，PHP 是 Facebook 最重要的語言，我們來看看 Facebook 都投入了哪些大牛到這個專案中（不全）：

  • Andrei Alexandrescu，『Modern C++ Design』和『C++ Coding Standards』的作者，C++ 領域無可爭議的大神
  • Keith Adams，負責過 VMware 核心架構，當年 VMware 就派他一人去和 Intel 進行技術合作，足以證明在 VMM 領域他有多瞭解了
  • Drew Paroski，在微軟參與過 .NET 虛擬機器開發，改進了其中的 JIT
  • Jason Evans，開發了 jemalloc，減少了 Firefox 一半的記憶體消耗
  • Sara Golemon，『Extending and Embedding PHP』的作者，PHP 核心專家，這本書估計所有 PHP 高手都看過吧，或許你不知道其實她是女的

雖然沒有像 Lars Bak、Mike Pall 這樣在虛擬機器領域的頂級專家，但如果這些大牛能齊心協力，寫個虛擬機器還是問題不大的，那麼他們將面臨什麼樣的挑戰呢？接下來我們一一討論。

規範是什麼？

自己寫 PHP 虛擬機器要面臨的第一個問題就是 PHP 沒有語言規範，很多版本間的語法還會不相容（甚至是小版本號，比如 5.2.1 和 5.2.3），PHP 語言規範究竟如何定義呢？來看一篇來自 IEEE 的說法：

The PHP group claim that they have the final say in the specification of (the language) PHP. This groups specification is an implementation, and there is no prose specification or agreed validation suite.

所以唯一的途徑就是老老實實去看 Zend 的實現，好在 HPHPc 中已經痛苦過一次了，所以 HHVM 能直接利用現成，因此這個問題並不算太大。

語言還是擴充套件？

實現 PHP 語言不僅僅只是實現一個虛擬機器那麼簡單，PHP 語言本身還包括了各種擴充套件，這些擴充套件和語言是一體的，Zend 不辭辛勞地實現了各種你可能會用到的功能。如果分析過 PHP 的程式碼，就會發現它的 C 程式碼除去空行註釋後居然還有80+萬行，而你猜其中 Zend 引擎部分有多少？只有不到10萬行。

對於開發者來說這不是什麼壞事，但對於引擎實現者來說就很悲劇了，我們可以拿 Java 來進行對比，寫個 Java 的虛擬機器只需實現位元組碼解釋及一些基礎的 JNI 呼叫，Java 絕大部分內建庫都是用 Java 實現的，所以如果不考慮效能優化，單從工作量看，實現 PHP 虛擬機器比 JVM 要難得多，比如就有人用8千行的 TypeScript 實現了一個 JVM Doppio。

而對於這個問題，HHVM 的解決辦法很簡單，那就是隻實現 Facebook 中用到的，而且同樣可以先用 HPHPc 中之前寫過的，所以問題也不大。

實現 Interpreter

接下來是 Interpreter 的實現，在解析完 PHP 後會生成 HHVM 自己設計的一種 Bytecode，儲存在~/.hhvm.hhbc（SQLite 檔案） 中以便重用，在執行 Bytecode 時和 Zend 類似，也是將不同的位元組碼放到不同的函式中去實現（這種方式在虛擬機器中有個專門的稱呼：Subroutine threading）

Interpreter 的主體實現在 bytecode.cpp 中，比如 VMExecutionContext::iopAdd 這樣的方法，最終執行會根據不同型別來區分，比如 add 操作的實現是在 tv-arith.cpp 中，下面摘抄其中的一小段

if (c2.m_type == KindOfInt64)  return o(c1.m_data.num, c2.m_data.num);
if (c2.m_type == KindOfDouble) return o(c1.m_data.num, c2.m_data.dbl);

正是因為有了 Interpreter，HHVM 在對於 PHP 語法的支援上比 HPHPc 有明顯改進，理論上做到完全相容官方 PHP，但僅這麼做在效能並不會比 Zend 好多少，由於無法確定變數型別，所以需要加上類似上面的條件判斷語句，但這樣的程式碼不利於現代 CPU 的執行優化，另一個問題是資料都是 boxed 的，每次讀取都需要通過類似 m_data.num 和m_data.dbl 的方法來間接獲取。

對於這樣的問題，就得靠 JIT 來優化了。

實現 JIT 及優化

首先值得一提的是 PHP 的 JIT 之前並非沒人嘗試過：

那麼究竟什麼是 JIT？如何實現一個 JIT？

在動態語言中基本上都會有個 eval 方法，可以傳給它一段字串來執行，JIT 做的就是類似的事情，只不過它要拼接不是字串，而是不同平臺下的機器碼，然後進行執行，但如何用 C 來實現呢？可以參考 Eli 寫的這個入門例子，以下是文中的一段程式碼：

unsigned char code[] = {
  0x48, 0x89, 0xf8,                   // mov %rdi, %rax
  0x48, 0x83, 0xc0, 0x04,             // add $4, %rax
  0xc3                                // ret
};
memcpy(m, code, sizeof(code));

然而手工編寫機器碼很容易出錯，所以最好的有一個輔助的庫，比如的 Mozilla 的 Nanojit 以及 LuaJIT 的 DynASM，但 HHVM 並沒有使用這些，而是自己實現了一個只支援 x64 的（另外還在嘗試用 VIXL 來生成 ARM 64 位的），通過 mprotect 的方式來讓程式碼可執行。

但為什麼 JIT 程式碼會更快？你可以想想其實用 C++ 編寫的程式碼最終編譯出來也是機器碼，如果只是將同樣的程式碼手動轉成了機器碼，那和 GCC 生成出來的有什麼區別呢？雖然前面我們提到了一些針對 CPU 實現原理來優化的技巧，但在 JIT 中更重要的優化是根據型別來生成特定的指令，從而大幅減少指令數和條件判斷，下面這張來自 TraceMonkey 的圖對此進行了很直觀的對比，後面我們將看到 HHVM 中的具體例子：

HHVM 首先通過 interpeter 來執行，那它會在時候使用 JIT 呢？常見的 JIT 觸發條件有 2 種：

  • trace：記錄迴圈執行次數，如果超過一定數量就對這段程式碼進行 JIT
  • method：記錄函式執行次數，如果超過一定數量就對整個函式進行 JIT，甚至直接 inline

關於這兩種方法哪種更好在 Lambada 上有個帖子引來了各路大神的討論，尤其是 Mike Pall（LuaJIT 作者） 、Andreas Gal（Mozilla VP） 和 Brendan Eich（Mozilla CTO）都發表了很多自己的觀點，推薦大家圍觀，我這裡就不獻醜了。

它們之間的區別不僅僅是編譯範圍，還有很多細節問題，比如對區域性變數的處理，在這裡就不展開了

但 HHVM 並沒有採用這兩種方式，而是自創了一個叫 tracelet 的做法，它是根據型別來劃分的，看下面這張圖

可以看到它將一個函式劃分為了 3 部分，上面 2 部分是用於處理 $k 為整數或字串兩種不同情況的，下面的部分是返回值，所以看起來它主要是根據型別的變化情況來劃分 JIT 區域的，具體是如何分析和拆解 Tracelet 的細節可以檢視Translator.cpp 中的 Translator::analyze 方法，我還沒空看，這裡就不討論了。

當然，要實現高效能的 JIT 還需進行各種嘗試和優化，比如最初 HHVM 新增的 tracelet 會放到前面，也就是將上圖的 A 和 C 調換位置，後來嘗試了一下放到後面，結果效能提示了 14%，因為測試發現這樣更容易提前命中響應的型別

JIT 的執行過程是首先將 HHBC 轉成 SSA (hhbc-translator.cpp)，然後對 SSA 上做優化（比如 Copy propagation），再生成本地機器碼，比如在 X64 下是由 translator-x64.cpp 實現的。

我們用一個簡單的例子來看看 HHVM 最終生成的機器碼是怎樣的，比如下面這個 PHP 函式：

<?php
function a($b){
  echo $b + 2;
}

編譯後是這個樣子：

mov rcx,0x7200000
mov rdi,rbp
mov rsi,rbx
mov rdx,0x20
call 0x2651dfb <HPHP::Transl::traceCallback(HPHP::ActRec*, HPHP::TypedValue*, long, void*)>
cmp BYTE PTR [rbp-0x8],0xa
jne 0xae00306
; 前面是檢查引數是否有效

mov rcx,QWORD PTR [rbp-0x10]           ; 這裡將 %rcx 被賦值為1了
mov edi,0x2                            ; 將 %edi（也就是 %rdi 的低32位）賦值為2
add rdi,rcx                            ; 加上 %rcx
call 0x2131f1b <HPHP::print_int(long)> ; 呼叫 print_int 函式，這時第一個引數 %rdi 的值已經是3了

; 後面暫不討論
mov BYTE PTR [rbp+0x28],0x8
lea rbx,[rbp+0x20]
test BYTE PTR [r12],0xff
jne 0xae0032a
push QWORD PTR [rbp+0x8]
mov rbp,QWORD PTR [rbp+0x0]
mov rdi,rbp
mov rsi,rbx
mov rdx,QWORD PTR [rsp]
call 0x236b70e <HPHP::JIT::traceRet(HPHP::ActRec*, HPHP::TypedValue*, void*)>
ret

而 HPHP::print_int 函式的實現是這樣的：

void print_int(int64_t i) {
  char buf[256];
  snprintf(buf, 256, "%" PRId64, i);
  echo(buf);
  TRACE(1, "t-x64 output(int): %" PRId64 "
", i);
}

可以看到 HHVM 編譯出來的程式碼直接使用了 int64_t，避免了 interpreter 中需要判斷引數和間接取資料的問題，從而明顯提升了效能，最終甚至做到了和 C 編譯出來的程式碼區別不大。

需要注意：HHVM 在 server mode 下，只有超過12個請求就才會觸發 JIT，啟動過 HHVM 時可以通過加上如下引數來讓它首次請求就使用 JIT：

-v Eval.JitWarmupRequests=0

所以在測試效能時需要注意，執行一兩次就拿來對比是看不出效果的。

型別推導很麻煩，還是逼迫程式設計師寫清楚吧

JIT 的關鍵是猜測型別，因此某個變數的型別要是老變就很難優化，於是 HHVM 的工程師開始考慮在 PHP 語法上做手腳，加上型別的支援，推出了一個新語言 – Hack（吐槽一下這名字真不利於 SEO），它的樣子如下：

<?hh
class Point2 {
  public float $x, $y;
  function __construct(float $x, float $y) {
    $this->x = $x;
    $this->y = $y;
  }
}
//來自：https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf

注意到 float 關鍵字了麼？有了靜態型別可以讓 HHVM 更好地優化效能，但這也意味著和 PHP 語法不相容，只能使用 HHVM。

其實我個人認為這樣做最大的優點是讓程式碼更加易懂，減少無意的犯錯，就像 Dart 中的可選型別也是這個初衷，同時還方便了 IDE 識別，據說 Facebook 還在開發一個基於 Web 的 IDE，能協同編輯程式碼，可以期待一下。

你會使用 HHVM 麼？

總的來說，比起之前的 HPHPc，我認為 HHVM 是值得一試的，它是真正的虛擬機器，能夠更好地支援各種 PHP 的語法，所以改動成本不會更高，而且因為能無縫切換到官方 PHP 版本，所以可以同時啟動 FPM 來隨時待命，HHVM 還有FastCGI 介面方便呼叫，只要做好應急備案，風險是可控的，從長遠來看是很有希望的。

效能究竟能提升多少我無法確定，需要拿自己的業務程式碼來進行真實測試，這樣才能真正清楚 HHVM 能帶來多少收益，尤其是對整體效能提升到底有多少，只有拿到這個資料才能做決策。

最後整理一下可能會遇到的問題，有計劃使用的可以參考：

  • 擴充套件問題：如果用到了 PHP 擴充套件，肯定是要重寫的，不過 HHVM 擴充套件寫起來比 Zend 要簡單的多，具體細節可以看 wiki 上的例子。
  • HHVM Server 的穩定性問題：這種多執行緒的架構執行一段時間可能會出現記憶體洩露問題，或者某個沒寫好的 PHP 直接導致整個程式掛掉，所以需要注意這方面的測試和容災措施。
  • 問題修復困難：HHVM 在出現問題時將比 Zend 難修復，尤其是 JIT 的程式碼，只能期望它比較穩定了。

本文轉自二郎三郎部落格園部落格，原文連結：http://www.cnblogs.com/haore147/p/5220330.html，如需轉載請自行聯絡原作者


相關文章