Nginx の動作設定見直し

　Nginx に乗り換えてから約 1.5 年ほど経過して最近では平和に運用出来ているが、ちょっとばかり無駄な設定も見えてきたのでちょっと手入れをして動作を見なおしてみた。

1. Proxy Cache から FastCGI Cache に切り替え

　Nginx と言えばフロントエンドとバックエンドを同一ホストで簡単に実現ができて、尚かつ Proxy Cache も用いればリクエストを捌く速度がかなり高速化出来る事が目に付く。
　サイトの特性次第だけど、WordPress を動作させる場合で尚かつホストが 1 台のみならわざわざフロントエンドとバックエンドと分けて Proxy Cache を使う必要も無いのではと思った。
　そこで今回、検証環境でじっくりと Proxy Cache と FastCGI Cache の速度差を検証してみたが、正直どっちも大差ない。場合によっては FastCGI Cache の方が早い場合もある。
　PHP の動作するポイントの多い WordPress だから FastCGI で PHP-FPM の出力をキャッシュしてくれた方が若干速いのかもしれない。

　そんなわけで FastCGI Cache を用いるように動作を変更した。
　Cache の Purge には Proxy Cache 時と同じ ngx_cache_purge Module の fastcgi_cache_purge というディレクティブを用いると良い。

　参考までに h2load による HTTP/2 接続時のベンチマークは次のような結果に。
　パラメータは h2load -n 10000 -c 10 URL で統一。

• Proxy Cache : 1260.20 req/s
• FastCGI Cache : 1413.13 req/s

　12% ほど速くなった。とは言えこれだけ捌こうとしても回線の帯域が絶対的に不足するので参考程度にしかならない物で 1 リクエストあたりに換算しても体感するのは難しいだろう。
　更に参考までに FastCGI Cache を切ってみると 23.93 req/s なんて正直やばいかなと言うレベルになる。

2. キャッシュする Method の限定

　色々なサイトを参考にさせて頂きつつ自分なりのヒネりもいれてやっていたが、「GET 以外はキャッシュしない」という制御を行うとき、$do_not_cache 等と変数をフラグとして用いる事があるが、これを次の様に表す物をよく見かける。というか自分もそうしていた。

    set $do_not_cache 0;
    if ( $request_method != "GET" ) {
        set $do_not_cache 1;
    }
(中略
    fastcgi_no_cache     $do_not_cache;
    fastcgi_cache_bypass $do_not_cache;

　if 文で Request Method が GET 以外だった場合に $do_not_cache に 1 を入れておくとキャッシュせず、且つ参照しようとしないと出来る。
　これを次の様にしてしまうと if 文を用いずとも同じ事が出来る。

    fastcgi_cache_methods GET;
    fastcgi_no_cache     $do_not_cache;
    fastcgi_cache_bypass $do_not_cache;

　if 文の多用は推奨されていないとドキュメントにあったので、こうして fastcgi_cache_methods で GET のみをキャッシュするようにしておけば conf の中身も少しスマートになる。他にもキャッシュさせない為の if 文があるがそれは替えが効かないので仕方無しとしている。
　fastcgi_cache_methods のデフォルトでは HEAD と GET だけど HEAD もキャッシュするとマズいから GET のみとしておこう。

おわりに

　長期的に運用している場合、偶には動作を見なおして何か良い方向に変化を加えられないかと考えれば多少なり勉強にもなるし、面白い物がある。今回の様に若干プラスの結果が得られることもあるから、暫く平和で放置しているような場合は今一度設定を見なおしたりしてみると良いかも知れない。