HHVM 的後續

官方對於 HHVM 的未來提出了說明:「The Future of HHVM」。重點就是他們不打算以 PHP7 為目標,打算關起來自己玩...:

Consequently, HHVM will not aim to target PHP7. The HHVM team believes that we have a clear path toward making Hack a fantastic language for web development, untethered from its PHP origins.

如果以 Packagist 上的資料來看 (PHP Versions Stats - 2017.1 Edition),HHVM 的數量應該是沒人了:

And because a few people have asked me this recently, while HHVM usage is not included above in the graph it is at 0.36% which is a third of PHP 5.3 usage and really hardly significant. I personally think it's fine to support it still in libraries if it just works, or if the fixes involved are minor. If not then it's probably not worth the time investment.

Comment 的地方有註明這是扣掉 CI 的量:

@ocramius: These numbers ignore Travis CI and other CI systems that set the "CI" env var in their workers. Without excluding those HHVM is around 0.95% so it's still low but those .36% is probably actual usage.

這樣就放心可以完全不用管 HHVM 了 XDDD

Symfony 4 將放棄 HHVM

PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越,參考下面的連結),這使得後來大家為了相容性與擴充性的考量,HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊,作者從 packagist.org 上得到的數據):

這使得 Symfony 決定在 Twitter 上蒐集意見,而後決定下一個 major version (4) 將不再支援 HHVM:「Symfony 4: End of HHVM support」。

馬上想到的是 Laravel 用了一堆 Symfony 的元件啊,之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用,甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。

PHP 的主力版本進入 7.0 與 7.1 了...

在「PHP Versions Stats - 2017.1 Edition」這邊分析了 Packagist 上的 access log 而得到的:

可以看到 PHP 7.0 與 7.1 總算是慢慢爬上來了... 另外一個頗有趣的數字是在 comment 提到的 HHVM

@ocramius: These numbers ignore Travis CI and other CI systems that set the "CI" env var in their workers. Without excluding those HHVM is around 0.95% so it's still low but those .36% is probably actual usage.


Wikipedia 換成 HHVM 的成果

維基百科基金會的人發表了將 PHP 換成 HHVM 後的成果:「How we made editing Wikipedia twice as fast」。


另外是已登入使用者 (通常是經常參與編輯的使用者) 的頁面產生時間也大幅改善:

另外帶來的好處是 CPU 使用率的下降:

再來就是看 PHP 7 能追上多少了...

維基基金會的 2014 年八月月報

維基基金會釋出八月月報 (好像晚了三個月?):「Wikimedia Foundation Report, August 2014」,在「Wikimedia Highlights, August 2014」有比較精簡的版本。

維基基金會在報告裡有提供一些 PV 相關的數據,包括 comScore 的數字與自己 server log 所統計出來的數據。另外也包含了財務狀況。

其中技術相關的是取自「Wikimedia Engineering/Report/2014/August」這頁。另外因為這是八月的資料,我順便偷看了九月與十月的「Wikimedia Engineering/Report/2014/September」與「Wikimedia Engineering/Report/2014/October」。

可以看到在測試 HHVM 的計畫,而且目前看起來還不錯:「[Wikitech-l] [Engineering] Migrating test.wikipedia.org to HHVM」,拿了 test.wikipedia.org 測試,其中 speed test 的部份有大幅改善:

1) Speed test: measure the time taken to request the page 1000 times over just 10 concurrent connections:

                        HHVM    Zend    diff
Mean time (ms):         233     441     -47%
99th percentile (ms):   370     869     -57%
Request/s:              43      22.6    +90%


2) Load test: measure how much thoughput we obtain when hogging the appserver with 50 concurrent requests for a grand total of 10000 requests. What I wanted to test in this case was the performance degradation and the systems resource consumption

                        HHVM    Zend    diff
Mean time (ms):         355     906     -61%
99th percentile (ms):   791     1453    -45%
Request/s:              141     55.1    +156%
Network (Mbytes/s)      17      7       +142%
RAM used (GBs):         5(1)    11(4)
CPU usage (%):          90(75)  100(90)

維基百科之所以沒有遇到太多問題,主要是因為所使用的軟體是 open source 而且夠大的關係,直接成為 HHVM 測試的一環:「Compatibility Update」。

不過目前看起來應該還是跑 PHP,沒有看到整個都轉換過去的計畫。

另外一方面,搜尋引擎的更換就沒有這麼順利,雖然換到 Elasticsearch 後改善不少,不過可以看到八月的報告這樣寫:

tarted deploying Cirrus as the primary search back-end to more of the remaining wikis and we found what looks like our biggest open performance bottleneck. Next month's goal is to fix it and deploy to more wikis (probably not all). We're also working on getting more hardware.


In September we worked to mitigate the performance bottleneck that we found in August. We found there to be no silver bullet but used the information we learned to pick and order appropriate hardware to handle the remaining wikis. We also implemented out significantly improved wikitext Regular Expression search. In October we've begun rolling out the wikitext Regular Expression search and received some of the hardware we need to finish cutting over the remaining wikis. We believe we'll get it all installed in October and cut the remaining wikis over in November.


In October we prepared for November in which we deployed Cirrus to all the remaining wikis by installing new servers installing new versions of Elasticsearch and our plugins. We also fixed up regex search which had caused a search outage.

這些報告的連結裡面其實有些不會在對外新聞稿上面的評語... XD


相較於 Ubuntu 的五年 LTS (Long Term Support),HHVM 的 LTS 只有 48 周:「HHVM Long Term Support」。

不過考慮到 PHP 的開發週期,這個時間長度不算太意外:

每 24 周會有一次 LTS release,而每個 LTS 支援 48 周。

今年 2014/09/11 要出的 HHVM 3.3 將會支援到明年 2015/08/13,這樣對於會需要使用 HHVM 的單位應該還算可以接受?

等穩定下來後 (不知道多久後) 也許會再拉長 LTS 的支援時間?

殺意甚濃的 PHP 相容方案:HippyVM

HippyVM 是透過 PyPy 的技術實做出來的 PHP 相容方案:

HippyVM is a reimplementation of the PHP language using PyPy technology.


Right now, HippyVM is 7.3x faster than stock PHP and 2x faster than HHVM, using a geometric mean.

GitHub 上的 hippyvm/hippyvm 可以看到目前的進展:

HippyVM right now works only on 64bit linux on x86 platform (this limitation is temporary though, the RPython toolchain supports 32 and 64 bit x86, ARMv6 and ARMv7 on windows, os x and linux).

目前還是 pre-release 版本,但這個逆襲的感覺好殺...

用 nginx + FastCGI 接 HHVM...

看到「HHVM, Nginx and Laravel」這篇文章,加上 Rackspace 香港的機器用起來很愉快,就開一台起來測試...

文章內的方法都 okay,只是在裝 HHVM 前少了一步把 key 加到 apt 內的指令:

apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 5A16E7281BE7A449

補上去以後 apt-get update 才會動 :p

速度上當然是沒話說,而且使用的習慣很接近 drop-in replacement 了... (更新檔案後不需要自己另外 purge cache,HHVM 會自己偵測到)

晚點來測試看看 ApacheFastCGI 接 HHVM,如果可行的話就更好了?(.htaccess 啊...)