Cache
関連エントリを訳しながら読んだ、だいぶ雑なメモ。
復習
-
cache-control
-
no-cache: キャッシュに変更が無いか ETag でサーバに確認する
-
no-stroe: 一切キャッシュしない
-
public: キャッシュが可能である(普通つけない)
-
private: セッションごとなどで違うので、中間キャッシュできない(クライアントは良い)
-
max-age: キャッシュを再利用できる最大時間
-
If-Modified-Since
-
If-Non-Match があればそっち優先
-
Last-Modefied を入れる
-
Etag
-
リソースのタグ
-
hash 値
-
更新されたかがわかる
-
If-Non-Match
-
Etag を入れて送る
-
validation して 403
-
Expires
-
Cache-Control 非対応クライアント向けの古いヘッダ
-
Cache-Control があったらこっちは無視
-
Pragma
-
HTTP/1.0 互換の為にある
-
no-cache 以外指定しない
Yahoo
performance research part2: Browser cache Usage - Exporsed
2007 年の調査
browser は80% をfetch につかっているので、そこを減らすのには効果がある。
full cache
empty cache
empty な理由
- first visit
- キャッシュが消えた
- ブラウザが設定により消した
- スーパーリロード
どのくらいキャッシュが使われているか
- 新しい画像をリクエストしたユニークユーザ数
- 新しい画像の PV
画像に Expires と Last-Modified に古い値を付けるように設定
毎回必ずリクエストを投げるようになる。(戻るボタンは別)
Last-Modified を conditional GET してくるので
304 Not Modified を返す
- 200: キャッシュはなかった
- 304: キャッシュがあった
割合を調べる
- 少なくとも一つは 200 だったユーザ/ユーザ全体 (ユーザごと)
- 200 レスポンスの数 / 200 + 304 レスポンス
初日こそみんなキャッシュが無いので empty cache 率が高いが、だんだん下がっていく。
しかし、ある一定値で止まった。
- ユーザの 40-60% が empty cache
- PV の 20% が empty cache
Web performance: Cache efficiency exercise
2015/4/14 の記事
yahoo の調査が 8 年前なので Facebook がやり直した。
Cache-Control
Etag
Expires
Pragma
Last-Modified
を送るが、 IE はバグがあるので
Cache-Control
Pragma
だけ。
- ヘッダが無ければ 200 と画像を送り、 L-M と ETag を保存
- I-N-M, I-M-S があれば 304 で L-M は I-M-S を送り返す
これを FB のサーチのところに置いた。
結果
25% 近くがキャッシュミスしてた
ブラウザ別にみると Chrome/Opera は高い。 IE は低い。
Firefox は v31 で 80% くらいだが、 v32 で直近のレスポンスヘッダを再利用するようになったらしいので、
ログが正しく取れないので外した。
モバイルではキャッシュヒットは 6~8 割の間。
ユーザ別にみると 44.6% が empty cache だった。
2007 年とそんなに変わってない。
追加
どのくらいキャッシュは残っているのか？
I-M-S から現在時間を引いて47h 50% が 47h
yahoo の調査が 8 年前なのでやり直す。
p50 で 50% が 47h
p75 で 25% が 260h
平均、 47h モバイルが 12h くらい。
結論
2007 年よりはよくなってる
80% だったのが 84% くらいにあっぷ
42% の人が 47h はキャッシュを使える
原因は単純に最近のサイトがでかい、 1M 級のものがある。
ブラウザを圧迫してる。
FB がしょっちゅうリリースしていると、キャッシュに影響するかと危惧したが、
特に問題はなさそうということがわかった。
2012 Chrome17
disk cache の詳細
http://dev.chromium.org/developers/design-documents/network-stack/disk-cache
多分デフォルト値はこれ(80MB * 4 = 320MB)
https://code.google.com/p/chromium/codesearch#chromium/src/net/disk_cache/blockfile/backend_impl_v3.cc&l=757
v3 じゃない古いバージョンはこれっぽい(240MB)
https://code.google.com/p/chromium/codesearch#chromium/src/net/disk_cache/blockfile/backend_impl.cc&l=50
320という数字は、ベンチを回して決めた。
これ以上大きくしても向上は取るに足らないし、むしろ lookup が遅くなり始める。
とにかく、大半(60%)のユーザは 320MB で、 25~30% のユーザは 190MB だけキャッシュ領域がある。
windows の chrome では
25% が 4h
50% が 20h
75% が 48h
でキャッシュを使い切る。
アクティブな browsing をしてると
25% が 1h
50% が 4h
75% が 10h
あっという間だ。
すぐに cache が埋まるということが、サーバの cache hit が思ったほど上がらないことを裏付けている。
他にも ricardo 曰く
- 7% が週一回は settings でキャッシュをクリアしている
- 19% が週一回は fatal cache corruption が起こってる
明示的だけじゃなく、何らかの理由でキャッシュが消えている。
Firefox では 60%
Chrome では 70%
くらいが full cache になっていない。
chrome でキャッシュはどう使われているか？
一度キャッシュがいっぱいになったら、キャッシュヒット率は中央が 45% のほぼ正規分布に則っている。
10% 以下のコンテンツが 7KB 以下
80% が 7KB ~ 48KB
99% が 110KB 以下
lookup についてはメトリクスが色々あるが、たいていは 0-1ms で速いが、
遅いのもままある。
いずれにせよ改善の余地がある。