目次
おぼえがき。
キャッシュの名前、その保存先、サイズを設定する。
// /etc/nginx/nginx.conf
http {
...
# cache
proxy_cache_path /tmp/nginx/cache keys_zone=cache1:10m;
}
サイズについては公式ドキュメントにこう書いてあります。
One megabyte zone can store about 8 thousand keys.
10m という指定だとざっくり 8 万個のキーが保存できそうです。
どういうときにキャッシュするかを設定する
いくつかポイントがあるが、とりあえず今回の設定内容を出します。
// /etc/nginx/conf.d/server.conf
server {
...
# cache
set $mobile "";
if ($http_user_agent ~* '(Mobile|Android)') {
set $mobile "SP";
}
set $do_not_cache "";
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
proxy_no_cache $do_not_cache;
proxy_cache_bypass $do_not_cache;
proxy_cache cache1;
proxy_cache_key "$mobile//$scheme://$host$request_uri$is_args$args";
proxy_cache_valid 200 301 302 30d;
proxy_cache_valid any 10m;
add_header X-Cache-Status $upstream_cache_status;
...
}
モバイル判定
Wordpress のテーマとして、レスポンシブではなくサーバサイドでモバイルとの何か差分を作っている場合、キャッシュも分けないといけません。
Wordpress では is_mobile() という関数が用意されていて、これをつかってモバイル判定ができるので、これに合わせて nginx も設定するとよさそうです。
vars.php in tags/4.9.5/src/wp-includes – WordPress Trac
今回はおおむね iPhone と Android だけという区別でいくので Mobile|Android という指定にしました。
set で変数を設定し proxy_cache_key にその変数を入れることで、キャッシュする内容をモバイルとそれ以外とで分けることができます。
キャッシュをしないとき
管理画面にログインしていたり、コメントフォームに投稿した名前が記録されていたりなど、ユーザのもっているクッキーに応じて、テーマ上で値が出し分けされる場合、その内容をキャッシュしてはいけません。 （ログインしていないのに管理バーが出ちゃうよ！）
comment_author_|wordpress_(?!test_cookie)|wp-postpass_ として示されるクッキーがあるかを判定すると良いみたいです。
ここもモバイル判定と同様に変数に入れます。
この変数は proxy_no_cache と proxy_cache_bypass で使います。 proxy_no_cache はレスポンスをキャッシュに保存しない設定で proxy_cache_bypass はリクエストに対してキャッシュを使ってレスポンスを送らない設定です。 どちらも 0 ではないときに有効になります。
キャッシュの有効期限
proxy_cache_valid を使うことで有効な時間を設定できます。
ステータスコードをスペース区切りで書き、その後ろに有効期限を記載します。使える単位は ms/s/m/h/d/M/y です。
Configuration file measurement units
ここでは、ステータスコードが 200 または 301 または 302 のときに 30 日の間保持するようにしています。
また any という記載はそれ以外のステータスコードすべてに対して適用されます。ここでは 10 分にしています。
キャッシュが使われたか確認する
$upstream_cache_status という変数を見ると、キャッシュを使ったかどうかがわかります。
Module ngx_http_upstream_module
値として、おおむね HIT か MISS 、期限切れの場合は EXPIRED 、キャッシュしない場合は BYPASS がそれぞれ HTTP ヘッダーに出ているはずです。それ以外はちょっとわかんないです。
nginx の再起動
設定した内容に問題ないかを確認し nginx の再起動やりロードをしないと設定が反映されません。
service nginx configtest
service nginx condrestart
このときに proxy_cache_path に設定したパスが存在しないと自動で作られることはないので、自分で作っておく必要があります。
キャッシュの削除
このままでは Wordpress で新しい投稿をしてもキャッシュはが有効な間は、新しい投稿についてはキャッシュ上のコンテンツからたどることはできません。 ここでは 30 日が有効期限なので、月 1 回しか更新することができなくなってしまいます。
手動でキャッシュを消す
proxy_cache_path に設定したパスにキャッシュファイルがもりもり作られるので、そのファイル群を消せばキャッシュはなかったことになります。
rm -rf なんかでどばーっと消すと良いでしょう。
毎回手動でキャッシュを消すのも面倒なので、 Wordpress から消せるようにします。
Wordpress で投稿を保存した時に自動でキャッシュを消す
// functions.php
function clean_nginx_cache($postId) {
exec('rm -rf /tmp/nginx/cache/*');
file_get_contents(get_permalink($postId));
}
add_action('save_post', 'clean_nginx_cache');
手動でやるものを Wordpress のアクションフックに設定して自動化したものです。 投稿を保存した時に自動でキャッシュを消し、なんならその投稿のキャッシュを作成することができます。
プラグイン API/アクションフック一覧/save post - WordPress Codex 日本語版
プラグインもありそうなので、そういうのを使ってもよいと思います。
“nginx cache” の検索結果 — WordPress プラグイン
nginx の設定でなんとかする
今回の環境では利用できなかったのですが（モジュールがないっぽい…？） proxy_cache_purge を使うと nginx 上でキャッシュ削除の設定ができるようになります。
おわりに
nginx + Wordpress の環境で proxy_cache を有効にした際の覚書です。
有効にした結果ですが、レスポンスに 500ms 掛かっていたページが 50 - 100ms ほどに収まるようになりました。あまりプラグインなども入れていない簡素なテーマを使っているところなのですが Wordpress って結構時間かかるんだなあ…。
今回のものはわりとシンプルなテーマ、プラグインの状況だったので設定することや考えることが少なかったのですが、マルチサイトやプラグインによる大幅な機能変更がついてくると、もっといろいろなことを考えないとうまくキャッシュすることが出来なくなりそうな予感がしています。
特に他人の情報が見えちゃうよ！とかはキャッシュあるあるかつ激ヤバ案件なので、そういった時には入念にテストも重ねて回避したいですね～。