HHVM-3.12.0にしたWordpressをLoader.ioからベンチマーク

3381 ワード
PHP benchmark HHVM WordPress PHP テキストリンク

以前HHVM3.6がリリースされた頃、こんなことをやった。Loader.ioを使ってWordPressのバックエンド構成を変えつつ性能を測ってみる、php-fpmとHHVM

で、HHVMのLTSとされる3.12.0がリリースされたので、またベンチを取ってみようという試み。前回とはWordPressおよびMySQLのバージョンも違うので、直接参考にはならないけど。

まず通常のベンチマーク

AMIはこちら。WordPress Powered by AMIMOTO (HHVM) インスタンスはc3.large。

ルールは前回と一緒。トップページと、管理パネルの記事一覧表示。

トップページ

前回と比較。

- HHVM3.6 HHVM3.12 (参考)Nginx Cache
平均レスポンスタイム 1566ms 1405ms 25ms
リクエスト処理数 5387 5995 346791

ちょっとだけ速い。。？ 誤差程度かな。そもそもキャッシュするしこんなもんで。

管理パネル

ログイン状態でも比較してみる。これも条件は前回と同じ。

- HHVM3.6 HHVM3.12
平均レスポンスタイム 8866ms 4652ms
リクエスト処理数 1429 3273

おや、倍くらい速いぞこれ。何かしら効率が上がったとか、WordPressがそもそも早くなったのかは不明だが良いことだ。
Failも無いしね。

補足:RepoAuthoritative

HHVM3.8以降でPHPのコードを事前にバイトコードに変換するRepoAuthoritativeという機能がついた。

Enabling RepoAuthoritative mode involves pre-compiling all of your source code into a bytecode repo.

通常はリクエストに応じて生成するバイトコードのを、ウォームアップ代わりに事前に生成したい時に使う。

変換にはhhvm-repo-modeコマンドをつかう。

※ hhvm-repo-modeコマンド、ソースではhphp/tools/oss-repo-modeに入っている。binに無い場合でも、大抵パッケージのどこかに入っています。

これ、HHVMを止めないといけないので注意。

$ time sudo hhvm-repo-mode enable /var/www/vhosts/
Stopping hhvm:                                             [  OK  ]
running hphp...
parsing inputs...

...中略

analyzeProgram...
analyzeProgram took 0'00" (786762 us) wall time
parsing inputs took 0'02" (2681877 us) wall time
pre-optimizing...
pre-optimizing took 0'00" (614471 us) wall time
creating binary HHBC files...
creating binary HHBC files took 0'17" (17448057 us) wall time
all files saved in /tmp ...
running hphp took 0'21" (21824534 us) wall time
Starting hhvm:                                             [  OK  ]

Success!

real    0m21.997s
user    0m36.008s
sys 0m1.400s

先日microでやったらいつまでも終わらなかったが、c3.largeでは21秒で終わった。リソースはに余裕が必要そうだ。

おわりに

HHVM3.12は、以前からかわらない安定度が保たれていた。どうやら高速になった部分もあるのかなー。