キャッシュについてまとめ

基本

リクエストが増えるとIO待ちが増えて処理時間の低下を引き起こす多くのWebサービスでは少数のファイルにリクエストが集中するこの参照頻度の偏りを利用する - 頻度の多いファイル⇒高速なデバイス - その他⇒ふつうのデバイス

用語 - キャッシュサーバ - オリジンサーバ

キャッシュサーバとしての設定とクライアントにキャッシュさせる場合の設定がある。（ヘッダフィールドの指定等）

基本的にキャッシュとオリジナルコンテンツと同じサーバにある場合その有効性は限定的。（コンテンツがすべてメモリのページキャッシュに乗っている場合キャッシュでなくてもメモリから高速に応答できるため）

キャッシュに関するディレクティブ

ngx_http_proxy_moduleに実装されている (proxyと書いてあるがnginxのみの静的ファイル配信の際にもこれを用いる)

proxy_cache_path 保存先パス keys_zone=キーゾーン名:サイズ

キャッシュの保存先とキーゾーンの設定

proxy_cache キーゾーン名|off

キャッシュに利用するキーゾーンを指定する

proxy_cache_key キャッシュキー文字列;

キャッシュのキーに使用する文字列を指定する

キャッシュの基本

proxy_cache_pathによってキャッシュファイルの保存先を指定する。キーゾーン名やその容量などのパラメタを指定する。どのキーゾーンに保存するかはproxy_cacheディレクティブを使用する。 proxy_cache_keyでキャッシュのキーとして使用する値を使用する。子の値をキーとしてキャッシュの同一性を確認する。（デフォルトはスキーム、プロキシ先のホスト名、リクエストされたURIをキーに使用する）

補足

プロセス間でキャッシュを共有するためキャッシュのメタデータを共有メモリに保存する。
ゾーンの必要容量=キャッシュの総容量÷1ファイルの平均サイズ*128B
キャッシュファイルの保存ディレクトリの内部階層の指定をできる

キャッシュマネージャの制御

proxy_cache_pathディレクティブのloader_files, loader_sleep, loader_threasholdでキャッシュマネージャを制御できる

有効期限の指定

キーゾーンごとのキャッシュ有効期限を設定する
オリジンサーバのレスポンスヘッダに有効期限を指定する
レスポンスヘッダで指定されなかった場合のhttpステータスコードごとの有効期限を指定する
キーゾーン
proxy_cache_pathにinactiveパラメータを指定する
指定した有効期限より長くリクエストされないとキャッシュファイルが削除される。
デフォルト値は10分間

2.レスポンスヘッダ - X-Accel-Expires - Cache-Control - Expires これらのヘッダフィールドをオリジンサーバからのレスポンスに付加することでキャッシュの有効期限を指定できる 3.ステータスコード毎に有効期限を設定 proxy_cache_valid [HTTPステータスコード] 有効期限; これを設定することでステータスコードごとに有効期限を指定できる

キャッシュ条件の指定

nginxはデフォルトでGET, HEADメソッドのレスポンスをキャッシュする。（上記の設定をした場合の話） - GET,HEAD以外もキャッシュしたい場合 proxy_cache_methodsディレクティブを使う - URLでキャッシュするか決めたい場合locationディレクティブを使う - それ以外の時proxy_cache_bypassとproxy_no_cacheを使う proxy_cache_bypass 1　のときレスポンスをキャッシュから取得しない proxy_no_cache 1 の時　レスポンスをキャッシュに保存しない (変数を使って1 0 を切り替える)

一時ファイルの保存先の指定

nginxはキャッシュするレスポンスを一旦一時ファイルに保存し、その後指定したフォルダに移動するそのため、一時保存先と保存先が違うデバイスだとファイルをコピーする必要がありIOが発生するこの一時ファイルの保存先はデフォルトはコンパイル時に指定明示的に指定する場合proxy_temp_pathを使用する proxy_temp_path 一時ファイルの保存先パス

キャッシュ更新負荷の削減

キャッシュを利用した場合リクエスト数を減らすことができるしかし失効した瞬間にリクエストがバーストする。キャッシュ失効は大きなネットワーク負荷やディスクIOの原因になりうる。

proxy_cache_revalidate on|off; キャッシュ更新の際にオリジンサーバに if-Modifed-Since, If-None-Matchヘッダフィールドで送って更新されていなかった場合304が帰ってくるので、帯域負荷を抑えられる。
proxy_cache_lock on|off もう一つの方法としてキャッシュロックがある。これを有効にすると同じURIに対してのアクセスを一つ目以外ブロックする。これによりアップストリーム鯖への問い合わせ回数を制限できるこのブロックのタイムアウトはproxy_cache_lock_timeoutで指定できて、デフォルトは５秒になっている。

クライアントにキャッシュさせる場合の設定

クライアントにレスポンスをキャッシュさせるための設定はヘッダフィールドに設定を付加して行う。

add_header ヘッダフィールド名値 [always] alwaysを付加すると404,500と行ったエラーの場合にもヘッダフィールドを付加できる。 (ヘッダの追加のみ行うためアップストリームで設定しているフィールドをaddしてしまうと重複して出力される) （重複されている場合の挙動は定義されていないため不具合の原因になる可能性がある）
関係するヘッダフィールド
- X-Accel-Expires 秒数キャッシュサーバのnginxがコンテンツキャッシュの有効期限として解釈する（一般のブラウザでは解釈されない！！！）
- Cache-Control
- Expires HTTp/1.1ではこの二つのヘッダでキャッシュの制御を行う
Expiresヘッダの制御
```
expires [modified] 有効期限;
expires epoch|max|off;
```
HHTP/1.1に準拠するヘッダはexpiresディレクティブで行う
```
expires 10d; #１０日間キャッシュを行う。
```
デフォルトではリクエストされた時点の時刻を起点に計算される modifiedをつけるとファイルの最終更新時刻からの有効期限になる。
```
expires modified 5d; #更新日時から５日までキャッシュされる
```
epochを指定した場合Expiresヘッダフィールドの値が1970/00:00:00になる(最古の値) maxを指定した場合もっとも未来の値になる。常に無効にしたい場合epoch、常に有効にしたい場合maxに指定する通常はexpiresでExpriresを設定するだけで期限を設定できるが、他の細かい制御をするには Cache-Controlヘッダが必要なため場合によってはadd_headerでCache-Controlを指定する必要がある。
Cache-Controlヘッダ
- max-age=秒数
- no-cache #キャッシュしない
- max-age=315360000 #未来の最大値(expiresのmaxと同じ)
- private #キャッシュの共有を禁止（ブラウザレベルでしかキャッシュしないようにする）
条件付きリクエスト

ブラウザ、キャッシュサーバのキャッシュ以外にトラフィックを最小化する手法として条件付きリクエストが存在する。キャッシュの期限が切れた際にキャッシュが有効か確認をし、無効であれば新しいレスポンスを受け取る方法。

条件付きリクエストには以下のヘッダが付与されている - If-Modified-Since: "レスポンスのLast-Modifiedヘッダ" - If-None-Match: "レスポンスのETagヘッダフィールド"

サーバはこれらの値を確認し送信するファイルの内容が前回のキャッシュと変更されていないと判断できれば、 304(Not Modified)を送信しファイル送信を省略できる。もし変更されていれば通常通りファイルの内容を返す。

一般的なブラウザは条件付きリクエストに対応しており、nginxでもproxy?cache_revalidateを使用すれば、条件付きリクエストによるキャッシュの有効性確認ができる。

Last-Modified

リソースの最終更新日時を指定する nginxが静的リソースを配信する場合は自動的に付与される。 Webアプリケーションの出力などには自動的には付与されない。

ETag

リソースを一意に識別できるユニークな文字列を指定する nginxではetagディレクティブで制御できる。

etag on|off; #(デフォルトon)

nginxではファイルの更新日時とファイルサイズから自動的に計算される。基本的にはEtagを増やした状態で構わない

秘伝のタレの解説

 location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
     try_files $uri @app;
     expires max;
     add_header Pragma public;
     add_header Cache-Control "public, must-revalidate, proxy-revalidate";
     etag off;
 }

画像ファイルのときパスに存在すればそれを配信クライアント側で永遠にキャッシュする privateの逆 privateの逆必ずサーバに再認証を行うキャッシュサーバに対して再認証を要求 etagをつけない（←！？

etagがなくても条件付きリクエストをやるのかもしれない