WordPressチューニング: WP Super Cache 導入

前回の記事でAPC (Alternative PHP Cache) を導入したものの、パフォーマンス・チューニングの目標値にまだ達していないので、WP Super Cache も導入する。

WordPressのページ・キャッシュには WP Super Cache のほかにも W3 Total Cache も有名だが、ゆっくりと…: WordPressキャッシュ系プラグインの比較とサイトに適した選び方 によるとボクのサイトには WP Super Cache のほうが良さそうだし、いろいろなキャッシュを同時に使うと古いデータがどこでキャッシュされているのかなどのデバッグが難しいので、まずはシンプルな WP Super Cache を試し、それでも目標に達せない場合 W3 Total Cache を検討することにした。

ページ・キャッシュを導入するに当たって気になるのは、左ペインにある「最近の人気記事」が正しくカウントされるかどうかだ。キャッシュから読み込むことで「最近の人気記事」のランキングがリアルタイムに更新されないことは気にならないが、キャッシュから読み込んだ場合にはカウントされないとなると、このウィジェットの意味をなさない。ありがいたいことに、ボクの使っている WordPress Populars Posts のChangelogの2.0.0に、Ajaxを使用することで WP Super Cache などのページ・キャッシュに対応したと書いてあるので問題なさそうだ。

WP Super Cache の設定はDescription の Recommend Settings を参考にして、以下のものをオンにした。

• キャッシュファイルの提供にPHPを利用する
• ページを圧縮し、訪問者により速くページを供給する
• 304 Not Modified ブラウザーキャッシング
• 既知のユーザー向けにはキャッシュしない
• キャッシュリビルド
• モバイル機器サポート
• 追加のホームページチェック
• 除外するユーザーエージェント: （なし）
• プリロード:
  • 1400分毎にリフレッシュ
  • 520件の投稿をプリロード
  • プリロードモード

ログインしていると（既知のユーザーだと）キャッシュされないのは編集作業には適しているけど、このままでは WP Super Cache が効いているかどうか分からないので、WordPressから一度ログアウトしよう。メインのWebブラウザーでログインして WP Super Cache の設定を行い、別のWebブラウザーでログインせずにページを表示すると作業しやすいだろう。WordPressのそれぞれのページのソースを表示して、最後に以下のような記述があり、再読込みしても日時が変わらなければ WP Super Cache は正しく動いている。

<!-- Dynamic page generated in 1.243 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2011-11-01 18:41:25 -->
<!-- Compression = gzip -->

ところが、ボクの環境では、個別投稿ページは問題なくキャッシュされるものの、http://rewse.jp/blog/ は再読込みするたびに日時が変わる、つまり再読込みのたびにキャッシュを再作成してキャッシュから読み込まないという問題が起きた。これは WP Super Cache のタブ「簡易」にあるキャッシュテスターを使うと、以下のように表示されることからも分かる。

キャッシュを準備するために http://rewse.jp/blog/ を取得: OK
http://rewse.jp/blog/ の最初のコピーを取得中: OK (1.html)
http://rewse.jp/blog/ の二つめのコピーを取得中: OK (2.html)
ページ 1: 2011-11-01 18:41:25
ページ 2: 2011-11-01 18:41:27
ページがマッチしません ! タイムスタンプが違うか見つかりません !

ソースコードを追ってみると、この問題は WP Super Cache 0.9.9.9 のバグであることが分かったので、フォーラムで報告しておいた。具体的には、WordPressの「設定 > 一般 > WordPressのアドレス (URL)」にディレクトリが含まれており、「設定 > パーマリンク設定 > 一般的な設定」が /（スラッシュ）で終わらないときに起きる。ボクの場合は以下のようになっていたのでこのバグを踏んだ。

ボクの環境では手っ取り早く以下のように直しているが、0.9.9.9以降のバージョンで開発者がきれいに直してくれることだろう。

if (
  (
    //$wp_cache_request_uri == '/' ||
    $wp_cache_request_uri == '/blog/' ||
    ( $wp_cache_slash_check && substr( $wp_cache_request_uri, -1 ) == '/' ) ||
    ( $wp_cache_slash_check == 0 && substr( $wp_cache_request_uri, -1 ) != '/' )
  ) &&
  ( wp_cache_get_cookies_values() == '' && empty( $_GET ) && $serving_supercache ) )

この修正により、キャッシュテスターも以下のような表示に変わった。

キャッシュを準備するために http://rewse.jp/blog/ を取得: OK
http://rewse.jp/blog/ の最初のコピーを取得中: OK (1.html)
http://rewse.jp/blog/ の二つめのコピーを取得中: OK (2.html)
ページ 1: 2011-11-01 18:41:25
ページ 2: 2011-11-01 18:41:25
両方のページのタイムスタンプがマッチしました !

また、キャッシュから返されている http://rewse.jp/blog/p/4165 にアクセスするたびに以下のSQLの結果が1ずつ増えるので、WordPress Populars Posts が正しく動いてるかも確認できた。なお、WordPress Populars Posts はログインしているユーザーのアクセスはそもそもカウントしないので、ログアウトしてから試す必要がある。

SELECT pageviews FROM wp_popularpostsdata WHERE postid = 4165;

それでは WP Super Cache によってどれだけ性能向上したかabを実行してみよう。

[root@oscar ~]# ab -c 2 -n 4000 http://rewse.jp/blog/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rewse.jp (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests


Server Software:        Apache
Server Hostname:        rewse.jp
Server Port:            80

Document Path:          /blog/
Document Length:        64051 bytes

Concurrency Level:      2
Time taken for tests:   39.813 seconds
Complete requests:      4000
Failed requests:        0
Write errors:           0
Total transferred:      257536000 bytes
HTML transferred:       256204000 bytes
Requests per second:    100.47 [#/sec] (mean)
Time per request:       19.907 [ms] (mean)
Time per request:       9.953 [ms] (mean, across all concurrent requests)
Transfer rate:          6317.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   0.8      1      22
Processing:     9   18   5.9     18     123
Waiting:        6   11   4.6     11     114
Total:         10   20   6.0     19     123

Percentage of the requests served within a certain time (ms)
  50%     19
  66%     20
  75%     20
  80%     20
  90%     22
  95%     25
  98%     34
  99%     46
 100%    123 (longest request)

チューニング前の Requests per second が0.56#/secだったものが100.47#/secに達した。目標の20#/secも超えたので、これにて今回のチューニングは完了とする。