最近お仕事でBEAR.Sundayを使っているのですが、キャッシュについての知識を深めるために調べてみました。
雑ですがメモとして記事に残しておきます。(随時更新予定)
Resourceのキャッシュストレージについて
- DevではDoctrineのArrayCacheが使われている (リクエスト終了ごとにキャッシュは消える)
- 本番ではProdModuleを使用するので、DoctrineのChainCacheを使っている。-> ChainCacheの中身はApcuCacheとFilesystemCache
Resourceのキャッシュ時に使用されるキーについて
リクエストURIがキャッシュのキーに使われる。
BEAR.QueryRepository/ResourceStorage.php at df29dd49239ac1e800f2f7ebe21329efa2b003d3 · bearsunday/BEAR.QueryRepository · GitHub
AuraRouterでURIを変えてた場合は？ -> 関係なくて、ResourceとしてのURIになる
Etagの生成箇所について
EtagSetterで生成している
BEAR.QueryRepository/EtagSetter.php at df29dd49239ac1e800f2f7ebe21329efa2b003d3 · bearsunday/BEAR.QueryRepository · GitHub
HTTPCacheのAnnotationがなければ基本的にはResourceのクラス名と$ro->viewの内容で決まる。
HttpCacheとResourceキャッシュについて
Cacheableアノテーションが場合
1回目のリクエスト
Httpリクエスト -> Resourceの処理 -> Resourceのキャッシュ生成 -> Etagの生成 -> レスポンス
2回目のリクエスト
Httpリクエスト -> Etagにより304レスポンスを返す
Cacheable + NoHttpCacheの挙動について
HTTP Request時に * ### Cache-Control:private, no-store, no-cache, must-revalidate こんな感じにリクエスト送られるのでクライアントキャッシュは使わない。
ただしResourceのキャッシュは使われる。
Httpリクエスト -> Resourceのキャッシュのチェック -> Resourceのキャッシュがあればキャッシュから。なければResourceを実行しキャッシュする
最後に
BEAR.Sundayのキャッシュは２つに分類出来るかと思います。
- Resourceキャッシュ
- HTTPキャッシュ
Resourceキャッシュはサーバ側のキャッシュ。
HttpCacheはクライアント側のキャッシュ。
@Cacheableは２つのキャッシュ(HTTP Cache, ResourceCache)に関わることなので、混乱しがちかと思います。
意図と違う動作をしているときは一旦 Cacheable + NoHttpCacheの組み合わせで使ってみて調べてみると良いかもしれません。
最後の最後に
BEAR.Sundayは素晴らしいフレームワークなのです。
もっとみんな使って行きましょう！
そしてノウハウを共有していきましょう！