ビューのキャッシュ戦略-クエリキャッシュとレンダリングされた出力キャッシュの関係

まず、私はデューデリジェンスを確保し、以前に出てきた質問を重複させないようにしています。stackexchangeやその他のさまざまな場所で、ビューのキャッシュや、さまざまなタイプのビューキャッシュの詳細（例：hereとhere）について説明している投稿が数多くあります。ただし、ビューキャッシュのさまざまなレイヤー間の関係と、それらがケース固有のキャッシュの決定にどのように影響するかを十分に説明している詳細はまだわかりません。簡単にするために、私はこの質問の範囲を、コントリビュートスペースで提供される他のレイヤーとは関係なく、すぐに使える7.x-3.xのキャッシュオプションに焦点を合わせています。

ビューは、ディスプレイごとに「クエリ結果」キャッシュと「レンダリングされた出力」キャッシュの2つの時間ベースのキャッシュレイヤーを公開します。各キャッシュに含まれる生データの詳細は明確ですが、それらの相互作用方法は明確ではありません。レンダリングされたキャッシュへのヒットがクエリキャッシュを完全にバイパスするのか、2つのレイヤーが別々に動作するのか、私は特に疑問に思っています。私は（のような旧主張するいくつかの参照見てきたこの1を）、および（のように後者を主張しているいくつかのこの1）。

理論1-個別のキャッシュレイヤー

最初は、各レイヤーが別々に「連続して」呼び出され、レンダリングされた出力キャッシュがそのCID内の実際のクエリ結果をハッシュするという印象（および期待）を抱いていました。このようにして、新しいコンテンツがビューに即座に反映されるようにしながら、最も負荷の高いクエリ後のロード/ビルド作業をキャッシュするエレガントな方法があります（ "クエリ結果"キャッシュがオフで、 "レンダリングされた出力"キャッシュがオン）。いくつかの簡単なテストは、レンダリングされた出力キャッシュが現在のクエリ結果を認識していない可能性があるため、これは不可能かもしれないことを明らかにしています。

理論2-レンダリングされた出力キャッシュがクエリ結果キャッシュを「包括」する

もう1つの可能性は、レンダリングされた結果キャッシュが、クエリ自体（結果ではない）のハッシュによってキー設定されることです。この場合、ヒットすると、クエリキャッシュやDBを参照する必要なく、レンダリングされた出力を直接返すことができます。これが事実である場合、「レンダリングされた結果」キャッシュよりも短い時間間隔で「クエリ結果」キャッシュを設定することはあまり意味がないと思います。もちろん、利点は、DBへの直接クエリを回避しながら、レンダリングされた出力をより頻繁に更新できることです（多くの動的テーマロジックまたは頻繁なエンティティ更新がある場合）。ただし、最も複雑なビュークエリを除くすべての場合、この種類の分離はそれほど有利に思えません。

理論2を指す「ブラックボックス」テストをいくつか実行しましたが、他にいくつかの設定が機能しているかどうか、またはビューのバージョンによって答えが異なるかどうかはわかりません。私もコードを少し調べましたが、ほとんどのビューのプラグインメソッドがドキュメント化されておらず、たまに追跡するのが難しいことがイライラしています。とにかく、これに対する答えは、他の人の参考資料として役立つと思います。

私はいくつかの内部ビューロジックを調べました。可能な限り、各理論から正しい要素がありますが、どちらも100％正確ではありません。両方のキャッシングレイヤーは独立しており、常に連続してチェックされるため、「レンダリングされた出力」キャッシュには、クエリレイヤーを「バイパス」する機能がありません。また、クエリの結果は何ではないクエリ結果への変更は、残念ながら、レンダリング出力の更新をトリガしないように、因子の任意のキャッシュキーにします。

7.x-3.x

「クエリ結果」キャッシュはで管理されview::execute()、「レンダリングされた出力」キャッシュはで管理されview::render()ます。execute()「レンダリングされた出力」キャッシュロジックの前に呼び出されるため、「レンダリングされた出力」キャッシュヒットはクエリレイヤーをバイパスできません。表示がキャッシュから完全に構築されるだけの場合、これがクエリの実行やクエリキャッシュのチェックに少しもったいない理由は、私には完全に明らかではありません。view::execute()キャッシュとは別に常に実行する必要がある他のロジック（アクセスチェック、フック、プラグイン管理）がたくさんあり、「クエリ結果」のキャッシュ部分を簡単に分離できないと思います。とにかく、その詳細は質問に少し触れていますが、おそらく他の誰かがコメントすることができます。

キャッシュキーに関しては、両方のキャッシュレイヤーが、ビュー名、表示名、キャッシュタイプ、そしてからの一連のコンテキスト「スタッフ」のハッシュによってキー付けされviews_plugin_cache::get_cache_key()ます。このget_cache_key()メソッドを見ると、いくつかの一般的なコンテキストデータ（ユーザーロール、言語、base_url）が常に考慮されていることがわかりますが、「レンダリングされた出力」の場合は、未処理のクエリ文字列もハッシュすることにより、少し時間がかかります。クエリ結果ではありません。したがって、生のクエリが変更されると、レンダリングされた出力は更新されますが、クエリ結果が変更された場合でも、レンダリングされた出力はキャッシュから返されます。

したがって、パフォーマンスの観点から、各キャッシュレイヤーは実際には個別に処理できると思いますが、「レンダリングされた出力」キャッシュは、「古くなった」データが表示される頻度を最も直接的に管理します。私はさらにそれを結論付けることができました：

• ビュー内のアイテムの基本リストの更新間隔は、いずれかのキャッシュ間隔が大きいか大きいか等しい（実際のアイテムリストは、特定のビューの両方のキャッシュが期限切れになるまで更新できません）。
• 特定のビューの「レンダリングされた出力」キャッシュが「クエリ結果」キャッシュの前に更新される場合、アイテムのリストは更新されませんが、各アイテムに表示されるコンテンツは更新できます（つまり、5秒前にリストに追加された新しいアイテムはまだ）表示されませんが、以前にリストにあったアイテムの5秒前に更新されたティーザーテキストは更新されます）。
• 「クエリ結果」キャッシュが最終出力に影響を与えていない場合でも、のパフォーマンスが向上しview::execute()ます。

この動作の一部は、views_plugin_cacheクラスのメソッドをローカルに上書きすることで変更できることにも注意してくださいviews_plugin_cache::get_cache_key()。

8.0.0

8.0.0-beta7以降、ビュー（コア）は時間ベースのキャッシュのオプションを保持しています。できれば7.x-3.xのように動作することを確認できますが、決定的なテストを行うには時期尚早です。このメタディスカッションをご覧ください。ただし、D8ビューもタグベースのキャッシュをサポートするように見えるため、ビューの時間ベースのキャッシュに関する懸念事項や制限の多くが問題になる可能性があることは明らかです。これは、キャッシュされたデータを本当にスマートに期限切れにする方法を提供するはずです。