キャッシュされたページが期限切れになったときに再構築する方法は？

この素晴らしいQ＆Aを読み、良い結果を得た後、ビューキャッシュを使用しています。ビューに「最後のコメント」を表示し、それらの変更を頻繁に行うため、有効期限を短くする必要があります。

コメントが追加されるたびにビューのコンテンツキャッシュを使用してキャッシュを期限切れにすることを考えています。または、ルールを使用してアクションをキャッシュします。

キャッシュが期限切れになった直後に再構築したいのですが？私はブーストモジュールがそれを提供することを読みましたが、認証された訪問者のためのソリューションが必要です（匿名にはVarnishを既に使用しています）。

キャッシュ優雅なモジュールだけで20回のインストール（プラス他のモジュールのカップルが必要です）を持っていることを提供しているようです。

キャッシュを期限切れにしてすぐに「ウォームアップ」できる他のソリューションはありますか？

キャッシュをウォームアップするために実行する必要がある関数がわかっている場合は、httprlをチェックアウトしてください。httprl_queue_background_callback（）は、使用を調べる関数です。バックグラウンドでウォッチドッグを呼び出す簡単な例http://drupalcode.org/project/httprl.git/blob/24a88acd2180191d0b54696e577f14615e37302d:/README.txt#l268

優雅なワニスキャッシュクリアに関して、これは良い例です：https : //www.varnish-cache.org/trac/wiki/VCLExampleGrace使用中の例：http : //groups.drupal.org/node/63203

Boost for Drupal 7は見事に機能し、その新しいCrawlerサブモジュールとCache Expirationモジュールのおかげで、条件付きで期限切れにして、選択したページを積極的に再キャッシュできます。このような設定では、ビューだけでなく上記の組み合わせで同じ動作を実現できるため、ビューコンテンツキャッシュなどのモジュールは必要ありません（キャッシュの有効期限はルールと統合されているため、可能性は本当に無限です）。このページでこれを機能させるための完全なレシピがあります。

https://www.drupal.org/project/recacher と呼ばれるかなり新しいモジュールがあります。これは、https：//www.drupal.org/project/expireおよびhttps://www.drupal.org/と連動します。 project / httprl_spider

すべてを再クロールする代わりに、expiresモジュール内で実行されたノードのみを再キャッシュします。

私のランドスケープでは、それはそのように機能するはずです：ノードの変更/作成->期限切れ-> Nginxからのパージ-> httprl_spiderでの再キャッシュ。

そうすれば、ほとんどの場合キャッシュが新鮮になります。

キャッシュウォーマーモジュールのコードを再利用できるカスタムモジュールと組み合わせて、キャッシュアクションモジュールを使用することを検討してください。

キャッシュのウォーミングは、さまざまなユーザー（ルールごとに1人のユーザー）として、変更された/望ましいURLをpingすることで実行できます。ユーザー資格情報と一緒にいくつかのcURL呼び出しを行う必要があります。Cache Warmerモジュールには、この呼び出しを行う方法のコードがあります。

したがって、キャッシュアクションモジュールを使用すると、特定のページのキャッシュをいつ解除するかを指定できます。その後のアクションでは、カスタムモジュールから関数を呼び出して、特定のURLまたはURLのセットをキャッシュウォーミングできます。

あなたの最良のオプションはエッジサイドインクルードだと思います。見てみましょう縁側統合が含まモジュールを。これについての引用は次のとおりです（モジュールのプロジェクトページから）：

ESI（エッジサイドインクルード）は、認証済みユーザー向けの高性能キャッシュソリューションですが、匿名ユーザーにも役立ちます。

通常、認証されたユーザー向けにパーソナライズされたページ（「Manarthとしてログイン」と言うブロックなどのマイナーなパーソナライズでも）は、リバースプロキシ（Drupalの100倍の速度で簡単に実行できる）がページをキャッシュするのを防ぎます。あるユーザーを対象としたものは、別のユーザーに表示される可能性があります。

ESIは、この問題に対処するためのW3C標準です。パーソナライズされたコンテンツは、ESIタグに置き換えられ<esi:include src="http://example.com/esi/block/xxxxxx" />ます。これは、すべてのユーザーで同一です。その後、ページをキャッシュできます。VarnishなどのエッジデバイスはESI URLをフェッチし、そのコンテンツをキャッシュページにマージします（そのESI URLのコンテンツもキャッシュされる場合があります）。

この手法は、パフォーマンスを容易に10倍、100倍、場合によってはさらに向上させることができます。