[翻譯] Facebook HHVM 團隊封閉開發三週成果展

本人翻譯的一篇文章,首發於伯樂在線php

【補充信息】HipHop for PHP是一系列PHP腳本語言的程式碼轉換器的集合,它包含HPHPc、HPHPi、HPHPd以及HHVM,這四個腳本引擎各有所不一樣,可是他們共用相同的執行時期(Runtime)及工具集(Toolset)。HipHop是由Facebook所創建,他們用它來節省服務器的資源。HipHop 由 C++ 和 C 語言所編寫,發佈時代碼量已高達60萬行,它以自由軟件發佈,採用PHP許可證3.01版。(摘自維基百科ios

2013年11月4日開始,HHVM團隊進行了爲期三週的「性能與兼容性封閉開發」。這次封閉開發於11月22日正式結束。整體來看,封閉開發得到了成功。衡量成功的三要素以下:laravel

  • 1. 對21款開源框架作測試後,咱們是否達到了平均單測經過率爲99%的目標。
  • 2. 咱們是否得到了15%的性能提高收益。
  • 3. 團隊成員是否能堅持三週不刮鬍子。

HHVM團隊在封閉開發結束後的聚會上git

兼容性

封閉開發伊始,團隊認識到,僅僅擁有優異的性能還不足以使HHVM成爲可靠的、可供大範圍使用的PHP運行環境。它必須能運行實際的、現成的PHP代碼。因此,咱們將這一點視爲頭號工做任務(它將持續進行至2014年)。首先,咱們在GitHub上經過「星標」數來尋找那些正被大多數人使用的熱門PHP項目,並確保這些項目的單元測試可順利運行於HHVM之上。github

兼容性成果

先來看一些數字。下圖是超過125次文件修改以後,取得的兼容性方面的部分紅果。正則表達式

封閉開發後的單元測試兼容性成果sql

框架數據庫

封閉開發前 %數組

封閉開發後 %緩存

Delta %

均值

89.96

99.58

9.62

assetic

77.94

100

22.06

codeigniter

88.24

100

11.76

composer

98.79

98.89

0.10

doctrine2

92.4

99.95

7.55

drupal

98.61

100

1.39

facebookphpsdk

100

100

0

idiorm

100

100

0

joomla

94.09

97.92

3.83

laravel

99.23

100

0.77

magento2

97.66

98.74

1.08

mediawiki

98.91

99.98

1.07

paris

100

100

0

pear

Fatal

92.66

92.66

phpbb3

94.58

99.5

4.92

phpmyadmin

96.15

94.16

-1.99

phpunit

96.29

97.03

0.74

slim

100

100

0

symfony

86.53

96.67

10.14

twig

99.23

100

0.77

yii

78.08

99.11

21.03

zf2

92.4

95.49

3.09

正如圖表及delta列所示,咱們在努力下,近乎徹底的成功改進了單元測試的兼容性。

  • 1. 團隊使可在HHVM上100%跑通單元測試的開源項目數量翻了一番(從4個到8個),而且有另外4個項目的經過率在99%以上。
  • 2. Assetic,Symfony,Yii和CodeIngiter四個項目的兼容性提高了10%以上。
  • 3. 所有21款框架的單元測試經過率均在90%以上。

大部分文件更改已包含在HHVM 2.3版本中,如下是一些對單元測試結果有顯著影響的關鍵改進:

  • 1. 不要使數組成爲Traversable接口的實例
  • 2. 國際化支持
  • 3. PDO::sqliteCreateFunction()方法實現
  • 4. 開始支持真實的php.ini文件。

不管怎樣,我相信你對咱們的成果還有一些好奇:

1. 爲何phpMyAdmin的兼容性降低了呢?  這並非「因爲咱們改動代碼形成單元測試失敗」這個維度上的降低。這實際上多是咱們的測試框架腳本在最初未能正確的載入所有測試用例形成的。咱們修復了這個問題。儘管如此,咱們正在調查這個降低的根本緣由,以防咱們破壞了某些東西。

2. 爲何在11月24日左右有一個垂直跌落。咱們提交了一處修改,本想將測試框架推向完美,但卻在運行時遭遇段異常。這個錯誤很快被修復了。

測試框架

正如前文所述,用來提高單測兼容性的21款開源項目是根據流行程度挑選出來的。不過,挑選還基於他們是否使用PHPUnit以及他們在咱們的框架上運行的如何。舉例來講,這些項目的單元測試數量,Symfony和ZF2各有超過一萬個測試用例,咱們須要一個能以較快方式運行全部項目單元測試用例的測試框架。所以,咱們開發了一個可並行下載、安裝和運行全部單元測試的腳本。這個腳本仍然在完善中,但它已幫助咱們在30分鐘到一個小時內運行五萬個以上的單元測試用例而且可連續運行不少個小時。這個腳本位於:HHVM Github repository

可能你已經注意到,你所喜好的開源項目並未出如今上面的名單中。這是因爲如下幾個緣由形成的:首先,咱們不可能在3周時間內覆蓋全部的開源項目。其次,雖然諸如CakePHP這樣的開源項目很重要,咱們也計劃將它們加入測試框架,但因爲一些安裝和配置方面的的問題(例如,要求數據庫)使咱們沒法在短期內完成這一工做。

最後,正如咱們在封閉開發前發表的博文中所述,HHVM團隊建立了不少「便利貼」來指引項目。便利貼顯示兩項內容:與便利貼上所述任務相關的失敗測試用例數及已開發天數。因此,咱們一般按從左上角到右下角的順序工做,以使咱們取得最大回報。

假設與警告

指出與上述統計值相關的假設及警告是頗有必要的。

1. 總體單元測試經過百分比(98.5%)是簡單的,未加權平均數(即,全部百分比相加除以21).所以,相似Paris這種只含有50個單元測試用例的項目和相似Symfony這種包含一萬單元測試用例的項目擁有相同的權重。若是咱們加權 (其中 Symfony 和 Zf2 會獲得比Pair和 Idiorm更多的權重)計算這些百分比,總體經過百分比會有極小的跌幅 (績效跌幅的緣由是由於在全部開源資源項目的經過百分比方差小)

2. 某些在HHVM上運行失敗的測試用例,一樣沒法在PHP 5.5.x環境中運行。咱們稱其爲「小丑」同時在咱們的測試框架中忽略他們。

3. 某些單元測試會致使咱們的測試框架腳本出錯(例如,死鎖)。咱們屏蔽了這些測試用例並把它們歸爲失敗用例。

已提交的相關項目的Pull Requests

爲了能成功運行全部開源項目的單元測試,咱們對它們的代碼作了屢次修改。例如,一些修改是爲了支持咱們的並行測試框架。在其餘一些狀況下,單元測試用例中實際bug。使人驚喜的是,就在咱們封閉期間,那些項目維護者就審查了代碼,並在大多數狀況下接受了咱們的pull requests。如下是一些pull request的實例:

框架 & pull request連接

描述

Pear

Support different style error messages

Doctrine2

Support the HHVM requirement of implementing methods of interfaces

Joomla

Support the definition usort() on equal values

phpbb3

Support our parallel testing framework

Slim

Support a string check in hash_hmac

Twig

Better use of strings instead of large integers in certain parsing scenarios

PHPUnit

Support HHVM in PHP_BINARY checks

Symfony

Support HHVM as one of the possible PHP executables

與Travis集成

HHVM 2.3版本公告中提到了與Travis CI集成。如今,咱們開始持續的經過開源項目的單元測試,一些開源項目已把HHVM加入它們的Travis CI構建(棒極了)。如下是把HHVM加入CI構建的開源框架:

感謝以上項目能如此之快的支持咱們。一樣,咱們對其餘項目也提交了不少相似的優秀pull request

性能

性能團隊的封閉開發目標是提高15%,最終得到了16%的提高。

封閉開發後的性能成果

這意味着其餘php代碼也會有很大的提高空間。性能方面的收穫來自於大量的小改進和少許的大改動。如下是一些重大的修改:

1. 爲特殊的函數調用方式生成代碼。HHVM已經爲普通函數和方法調用生成優質的代碼,因此一些不常見的調用方式已經出如今咱們的性能配置數據中。兩個最大的改動點是 call_user_func()和static::方法調用已被解釋器處理。如今HHVM可爲每種調用類型生成優化過的機器代碼。

2. 優化HHVM二進制的佈局。HHVM是一套龐大的程序:編譯後的HHVM時鐘C++代碼略低於100MB。當最頻繁調用的代碼佔用空間少而不是分散在地址空間中時,CPU緩存才工做的更好。因此,咱們把最經常使用函數集合在一塊兒做爲二進制的一部分。爲了提高頁表緩存性能,咱們使用一個巨大的頁來映射這個部分。

3. 使用解釋器檢測熱點函數。HHVM解釋最初的幾個請求,以避免浪費時間和空間去編譯啓動代碼。咱們爲解釋器加入了尋找熱點函數並將其編譯爲轉換緩存一部分的功能。就像最後一個優化,這一項優化針對動態生成的代碼,改進了代碼位置。

4. 升級了咱們的正則表達式庫。新版PCRE加入了針對正則表達式的JIT編譯器,這爲HHVM帶來了一個使人興奮的性能提高。

我的衛生

我確信你在想:」全部的這些收益和統計很很好,可是鬍子呢?! ? 「沒錯,你還記得咱們再封閉開發前的博文:」剃鬚即失敗」。我很高興的宣告,咱們在封閉開發中一樣成功地維持一個最低限度的面部衛生。這裏有一些圖片來證實這一點。


HHVM團隊人手一把剃鬚刀,準備對面部作清理

咱們達到目標了麼?

還記得咱們在前文提到的成功三要素麼?

  • 1. 對21款開源框架作測試後,咱們是否達到了平均單測經過率爲99%的目標。
  • 2. 咱們是否得到了15%的性能提高收益。
  • 3. 團隊成員是否能堅持三週不刮鬍子。

答案是:

  • 1. 接近完成
  • 2. 完美完成
  • 3. 完成。

將來(2014)

性能改進將永遠是HHVM團隊關注的核心。兼容性優先級將爲1A。咱們很是關心開源和PHP社區。咱們將在2014年不遺餘力讓HHVM在性能與兼容性兩方面成爲一流,讓愈來愈多得開源項目及框架的單元測試(被)經過。大規模的真實php代碼測試。請繼續關注咱們的進展和計劃。最後,祝你們新年快樂。

原文連接: HHVM   翻譯: 伯樂在線 TechZi
譯文連接: http://blog.jobbole.com/58097/
相關文章
相關標籤/搜索