WordPress高速化をいろいろやってるんですが、ついにphp-fpm/PHP7から、HHVMに変更してしまった。その他もいろいろ調整して、今はnginx+HHVM+MariaDBという、意外にシンプルな構成になっています。結果、いろいろ凝ったことしなくても十分に性能の出る環境ってのは管理・運用が楽だということを実感しています。
なぜこんなことになったか、というお話です。
nginxのキャッシュもmod_pagespeedも使わない。シンプルな構成で。
これまで、いろんな高速化策を行ってきましたが、結局、あちらを立てればこちらが立たず状態で、手間ばかりかかっていることに気付きました。最終的な決め手は、mod_pagespeedでCSS/JSを書き換えると、「マテリアル」テーマの表示が乱れる事象が直せなかったためです。
速度という意味では、当然キャッシュを使えば確実に速くなるんですが、それに起因するトラブルもついて回ります。その辺のケアに気を使うくらいなら、いっそキャッシュ無しで速いエンジンで良いのではないか、と考えました（そもそもnginxは静的コンテンツの配信は十分に速いですし）。
そこで、PHPエンジンをHHVMに切り替えてみました。mod_pagespeedも含めキャッシュ系プラグインは一つもない、シンプルで高速なサイトにリニューアルです。
PHPエンジンをHHVMへ変更
HHVMとは何かと言えば、実行時コンパイル（JIT）でPHP、Hackが動くシステムです・・・と、これはWikipediaの記述のままですが、OPcacheが中間コードまでコンパイルして実行するのに対して、HHVMはバイナリレベルまでコンパイルして動きます。つまり速い。JITという技術はJava等では一般的な手法です。
という訳で、php-fpmからHHVMに変更。
このブログサーバーは、そもそもnginx、php-fpm、MariaDBをdockerコンテナで動かしているので、APレイヤのphp-fpmの差し替えは簡単です。HHVMのコンテナを追加で構成し、nginxコンテナを再作成してlinkを追加して、あとは適宜、FastCGIの振り先をphp-fpmからHHVMに変更するだけで行けてしまう。
HHVMについては、Debian/Ubuntuのパッケージがあるので、コンテナイメージとしてはUbuntuを使います。この辺、ホスト環境や他のコンテナの環境に依存しない辺りも、dockerの良いところです。
最後、動かす時、権限の調整は要注意です。
HHVMには、uidを指定する設定があるんですが、これが効きません。シングルプロセス構成なので、権限の移行がうまく行かないとか、開発者ブログでも見かけましたが、流石にrootで動かすのは気が引けます。通常、Webサーバーはコンテンツオーナーと同じuidで動かします。一般には、apacheユーザー。ウチの場合は、nginxユーザーです。
そこで、起動時はsudoかましています。当然ながら、pidファイルとログ・ファイルについては、所定の権限で書けるようにパーミッションの修正が必要です。
sudo -u nginx hhvm --mode server -d hhvm.server.type=fastcgi -d hhvm.server.port=9000 -d pid=/var/run/hhvm/pid
動作確認としては、ブログアップやメディアのアップロード等を行い、ファイルがコンテンツオーナーで更新されていることを確認できればOKです。rootで動かしてると、rootでコンテンツアップロードが成功してしまうので、実際ファイルの権限を確認したほうが良いです。
また、プラグインの中では、APCuが使えなくなりましたので、object-cache.php（※ドロップインで配置したphpファイル）を除去しています。基本、HHVMではOPcacheもAPCuも使わない（使えない？）構成になります。
php-fpm等でバックエンド連携をFastCGIにしてあれば、ここの切り替えは本当に簡単です。
シンプルで高速な構成は良い
さて、置換してかれこれ1日以上動かしていますが、特に問題はありません。mod_pagespeedを含め、いろいろ削除してしまったため、PageSpeed Insightsのスコアが落ちるようなことが懸念されましたが、実はそんなに変わっていません。むしろ応答速度が上がった方を高評価されているような感じです。凝ったことするより、シンプルに高速に仕上げたほうがやっぱり良かったんだな、って思います。
という訳で、ついにHHVMに辿り着いてしまったという話。なんか呆気ない感じ。
コメント