BEAR SundayのResourceのCacheについて調べたことメモ

BEAR SundayのResourceのCacheについて調べたことメモ

November 13, 2019,
tags: BEAR Sunday


このエントリーをはてなブックマークに追加

最近お仕事で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のキャッシュは2つに分類出来るかと思います。

  1. Resourceキャッシュ
  2. HTTPキャッシュ

Resourceキャッシュはサーバ側のキャッシュ。
HttpCacheはクライアント側のキャッシュ。

@Cacheableは2つのキャッシュ(HTTP Cache, ResourceCache)に関わることなので、混乱しがちかと思います。
意図と違う動作をしているときは一旦 Cacheable + NoHttpCacheの組み合わせで使ってみて調べてみると良いかもしれません。

最後の最後に

BEAR.Sundayは素晴らしいフレームワークなのです。
もっとみんな使って行きましょう! そしてノウハウを共有していきましょう!

参考リンク

BEAR.Sunday のリソースキャッシュを試してみた

comments powered by Disqus