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 がやり直した。

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 で速いが、
遅いのもままある。

いずれにせよ改善の余地がある。

TODO

IE の場合 http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-explorer-9-network-performance-improvements.aspx

Browser Cache - High Performance Web 2015