WordPress速度向上結果

がとらぼのここ幾つかのWordPress高速化の記事では結果の数字を出してないので本当に速くなってるの?ってことで計測してみた。
今回はIntel Pentium G630T (2.30GHz)というかなり遅い石を積んだFreeBSDサーバでNginx1.11.3, PHP7(php-fpm), OPCache(PHP), MySQL5.6, WordPress4.6, Twenty Thirteen(テーマ)という組み合わせ。

計測にはWeb Benchmark1.5を使用。これは指定したURLのページ本体のみ(または指定したファイル)を繰り返し取得するもの。ページURLを指定した場合、ページ内の画像やCSS,Javascriptなどは取得しないのとページを取るだけでレンダリング(表示処理)などは行わない。キャッシュの有用性を調べるには都合が良いが普通の閲覧者がブラウザでページを表示する速度とは大きな乖離があるので念のため。

ノーマル

同時接続1
Speed=1,866 頁/分, 367,850 bytes/秒
基準比 1.0倍(これを基準とする)

同時接続4
Speed=3,402 頁/分, 670,647 bytes/秒
基準比 1.8倍

YASAKANI Cache ログ有効(All request url)

同時接続1
Speed=40,656 頁/分, 6,291,537 bytes/秒
基準比 21.8倍

同時接続4
Speed=67,466 頁/分, 8,066,325 bytes/秒
基準比 36.2倍

YASAKANI Cache ログ無効

同時接続1
Speed=63,528 頁/分, 7,876,952 bytes/秒
基準比 34.0倍

同時接続4
Speed=170,860 頁/分, 13,629,633 bytes/秒
基準比 91.6倍

APCu

同時接続1
Speed=124,948 頁/分, 11,905,993 bytes/秒
基準比 67.0倍

同時接続4
Speed=279,500 頁/分, 21,500,948 bytes/秒
基準比 149.8倍

なお、全計測でオペコードキャッシュであるPHPのOPcacheが有効。

YASAKANI Cacheはデータを個別ファイルにキャッシュするのではなくSQLiteデータベースに保存するがSQLiteは高速なので同時接続1で基準比21.8倍(677.6頁/秒)とかなり健闘している。
APCuはキャッシュデータをメモリに入れてるので同時接続1で基準比67倍(2082.5頁/秒)とチートかよってほど速い。
ただし、実際にブラウザで観るとインターネット経由による遅延やページの部品集め(Javascript,CSS,画像,フォントなど)、ページ描画が大きな時間を取るので上のような数十~150倍というような性能向上にはならない。少し良くなる程度。
でも、速度向上はたとえ僅かでも重要。

WordPressを動かしているサーバでAPCuを使えるならAPCuが第一候補、APCuが使えなくてSQLiteモジュールが使えるならYASAKANI Cacheが第二候補、APCuもSQLiteも使えないけどmod_rewriteは使えるならその他のファイルキャッシュプラグインってところかな。

Googleマップで台風10号を表示してみた

台風データはJoint Typhoon Warning Centerから2016年8月27日23:40に取得したもの。上の地図のデータは更新しないので8月28日以降の予想進路については実際のコースと異なるかも。

灰色の○の中に×マークと灰色の渦巻きアイコンはクリックするとその時点(名前:YYMMDDHHZ)の速度(ノット)が表示される。
青いマーカーをクリックするとその時点(名前:DD/HHZ)と速度(ノット)だけでなくその他の説明も表示される。

台風10号が珍しい動きをしているので記念 & Googleマップのこんな利用方法もあるのね、ふーんっていう記事。

WordPress用ファイルキャッシュ Yasakani Cache

WordPress用にYasakani Cacheという新しいキャッシュプラグインが登場した。
日本人が作っていて日本語の説明ページもあるのでこの手のプラグインが苦手な人も安心。

Yasakani Cacheはファイルキャッシュ(データキャッシュ)。
ファイルキャッシュ系のプラグインは設定が難しく動作に罠があったりで苦労させられることが多い。ウェブサーバ側の設定にも手を付けなければならないことも多いのでとっつき難いという印象も。プラグインによっては.htaccessなどにmod_rewrite周りの設定を自動的に追加してくれるのでウェブサーバがApacheであれば難しくないという場合もあるけど勝手に変えられたせいで自分が指定した設定が台無しになることも。
Yasakani Cacheではキャッシュを高速なSQLiteデータベースファイルに置くという方法を採ることでウェブサーバ側に設定を追加する必要がなくなっていて、ウェブサーバがApache以外でも面倒が無い。そもそも導入については殆ど何も考える必要がない。Yasakani CacheプラグインをWordPressの管理画面の「プラグイン」から検索・ダウンロード・有効にしてYasakani Cache設定ページで「ページキャッシュ」を「有効」にするだけ。

Yasakani Cache 1
Yasakani Cacheの設定画面でページキャッシュを「有効」、ログモードを「All request url」にして「設定更新」。
利用しているホスティングサーバでSQLiteモジュールが使えない場合はこんなエラー。(左下のphp_errorの薄橙の部分にマウスポインタを置いて1秒待つとエラー内容が表示される。)
もちろんYasakani Cacheの設定でキャッシュを「有効」にしていても機能しない。
PHPのSQLiteモジュールが使えない(ホスティング)サーバでは使用を諦めるしかない。

Yasakani Cache 2
SQLiteモジュールが使えるサーバで設定は上と同じ。設定後に管理者画面からログアウトしてサイトのページを表示・再表示するとこんな感じのログになる。ログは新しいのが上、古いのが下。
左下のType列で「Store」になっているのがキャッシュ作成。「not_modified」はキャッシュが読み出されている。

キャッシュされているページ数は一番上の[Valid Cache]に表示される。

投稿や固定ページを更新した場合などはキャッシュは自動的に再作成されることになるようだが、テンプレートを編集したとかメニューやウィジェットを変更した場合は「キャッシュクリア」してやる必要があるみたい。

動作確認後の通常運用時のログモードは「無効」で良い筈。

記事にしたことがあるWP Super Cacheなどに比べると変なクセが無いのとNginxなどApache以外のウェブサーバでも何も考えずに気軽に使えるので凄く良いと思う。
ただし、データキャッシュ方式なので例えばテンプレートのPHPファイル内でアクセスしてきたブラウザのリファラを基に条件分岐してPC用とスマホ用に表示分けするような仕組みのサイトだと導入するべきでないし、動的に表示を変えるようなサイトでもやはり使うわけにはいかないと思われる。レスポンシブなテンプレートの場合はサーバからブラウザに送るデータは同じで、ブラウザ側でレイアウトを調整するのでデータキャッシュとの相性は良い。
(Yasakani Cacheはwp_is_mobile()を使ったPC用/モバイル用の表示分けには対応しているらしいのでwp_is_mobile()以外の分岐が要注意)

他のデータキャッシュと併用しても表示速度向上は望めない。例えば一つ前の記事のAPCuと併用しても意味が無い。