Loader.ioをそのうち試そうとしていたところに、丁度いい相談があったのでやってみた。
プラットフォームの要素を変更したWordPressでパフォーマンスを比較したいとのことだ。
HipHopVM(HHVM)のAmazon Linux用RPMを作った
HHVMはFacebookの言語Hackの実行エンジン。細かい話は置いといて、HHVMのバージョン3.6は5.6相当のphp実装でもある。
Amazon Linuxをベースにしつつ、HHVMでWordPressを動かしたいと言われ、RPMでだれでも使えるようにしていいならしばらく面倒見てもいーよと。
で、test-kitchenでRPM作れるようにして、walter-cdでポイっとリリースできるようにしたのが次のリンク。
OpsRockin/hhvm-for-amazon-linux
できたものはpackagecloudで配布中、と。
opsrock-hhvm/hhvm-stable - Packages
HHVMのRPMを元に、AMIMOTOシリーズにHHVMをラインナップしてもらった
少し前からHHVMに興味津々だったWordPressのAMIMOTOにRPMを渡すと、ほどなくHHVMを使ったWordPressがAmazon MacketPlaceに並びました。
既存のHVM版との要素はこんな感じで違います。 HVMとHHVMとタイトルが付いておりすこし紛らわしい。
| - | AMIMOTO HVM | AMIMOTO HHVM |
|---|---|---|
| Virtualization Modes | HVM | HVM |
| HTTPエントリ | nginx | nginx |
| upstream | fastcgi | fastcgi |
| PHPランタイム | php-fpm (5.5) | hhvm (5.6相当) |
| DB | Percona | Percona |
これをそれぞれインスタンスタイプc3.largeで起動し、WordPressのインストールとloader.ioのverifyまで済ませる。
nginxのキャシュプラグインが入っているので、これはOFF。
リージョンはloader.ioに近そうなのでus-east-1を選択。
Loader.ioのリクエストセッティング
普段こういうのは大抵httperfあたりを使うんですが、Loader.ioは結果をシェアしやすいのと、地味に性能が必要なクライアントマシンと回線の用意が無いのでやってみた。
無料プランなのでテストは1分間、上限は10000クライアント。ホストを変えると結果のアーカイブがクリアされちゃうのは仕方ないところか。
- Duration: 1分
- Type: 期間中2クライアント数を0-300まで増加(Maintain client load)
比較は2つの指標で。
トップページ表示
とりあえずトップページに対してクライアントを増やしながら全力アクセス。これは特に説明不要か。
nginxキャッシュを切っているので、毎度毎度トップページを生成させます。
php-fpm版に対して実行
まずはphp-fpmのAMIMOTOに対して実行。
クライアントの増加に対し、ほぼ線形に平均のレスポンスタイムも遅延していくのがよく分かる。
hhvmに対して実行
つづいてhhvmのAMIMOTOに対して実行。
同じように見えるが、青軸のスケールが違うね。次で比較しよう。
トップページ簡易比較
分かりやすい所をピックアップしてみた。
| - | AMIMOTO HVM | AMIMOTO HHVM | (参考)nginxキャッシュ有効 |
|---|---|---|---|
| 平均レスポンスタイム | 3108ms | 1566ms | 15ms |
| リクエスト処理数 | 2637 | 5387 | 386830 |
同じインスタンスタイプだけども、処理数が倍違う。
WordPressの管理画面の記事一覧を表示
Loader.ioでも複数のリクエスト間でサーバレスポンスの値を使えます。WordPressはCookieが使えればいいみたいなので、次の2つ
- 管理画面ログイン (POST /wp-login.php )
- 記事一覧表示 (GET /wp-admin/edit.php )
これならphpの処理系としての実力がさらに顕著に出るかも？
厳密には1で返されるリダイレクト先(/wp-admin/)にもリクエストを送るようなので3回づつリクエストが発生していたけど、リダイレクト時にCookieは持ち回ってくれないみたい。
ツールにWordPressでログインの処理をさせる時は、Post用のパラメータとして次の項目を埋めればOKだった。
- log : ユーザ名
- pwd : パスワード
- wp-submit :
Log+In - testcookie : 1 (いらないかも)
Cookieの使い回し方はLoader.ioのヘルプで。
Variables - Loader.io Help Desk
ついでに、管理画面は重たい事がわかっているのでレスポンスが50xになってしまってもベンチマークが中断しないようにエラー許容レートとタイムアウトを伸ばしておく。
増やした理由はすぐに。
php-fpm版に対して実行
では、ログインと管理用データ取得という重たげな処理をやってみよう。まずphp-fpm。
レスポンスタイムが途中から劇的に早くなった？？ のではなく、150−200クライアントのあたりでエラーで落ちている。
次の図、レスポンスコードの推移が分かりやすい。
php-fpmのエラーログには幾らか原因が出ていたので、チューニングの余地はあるかもしれないが。。まあ大抵こうなるよねと。
hhvmに対して実行
同じことをhhvmに対しても実行した。
レスポンスタイムこそ伸びた(defaultの10秒ではタイムアウト扱い)ものの、エラー無しで完走。ちょっとこれ内部の取り回しどうなってんだろと思いました。
hhvmはこの後さらに数千までクライアントを増やしたが、先にnginxのパラメータチューニングが必要だったほど安定していました。
さいごに
hhvmは早い上に頑丈だった。PHPと完全に互換があるわけではないらしいということだけど、採用できるPHPアプリケーションなら検討もしくは対応していいとおもう。
Amazon Linux用のHHVM-RPMはビルド関連もオープンなので、オプションなどリクエストがあればフィードバックもらえると多分対応します。
ベンチマークの裏でサーバにログインしてモニタリングしていると、どっちもCPUコア2つのうち片方しか使えてなかった感じなので、そこらもっと改良できるかも。
Loader.ioは定期的に実行しつつSlackに結果を通知してくれたりするので、たまに本番環境の健康診断とか、ちょっとした環境の評価に使うのもいいですね。
追記：
本記事の画像はこちらにも提供しました。 >> 網元HHVMの提供開始 | 超高速 WordPress AMI 網元