ランダムキャッシュの有効期限

私はランダムなキャッシュの有効期限を実験して、個々のリクエストが複数のものを一度に更新する状況を回避しています。たとえば、Webページには5つの異なるコンポーネントが含まれる場合があります。それぞれが30分でタイムアウトするように設定されている場合、ユーザーは30分ごとに長い待機時間を持ちます。そのため、代わりに、15〜45分のランダムな時間にすべてを設定して、特定のページのロードで最大1つのコンポーネントのみがリロードされるようにします。

このトピックに関する調査やガイドライン、たとえば最適分散パラメーターを見つけようとしています。Google（？）がこの手法をどのように使用しているかについての記事を1つ見たのを覚えていますが、それを見つけることができず、そのトピックについてあまり書かれていないようです。

いくつかの文書：

• キャッシュの最適化からレッツ・メイクウェブ高速化のGoogleシリーズを（私はあなたがこれを意味と仮定します？）
• キャッシングのチュートリアルでmnot.net
• 関連するSOの質問もいくつかあります。
  • Google PageSpeedが推奨するHTTPキャッシュの有効期限を設定する
  • GoogleとYahooが推奨するHTTPキャッシュの有効期限を設定する
• また、StackExchangeがホストするその他の質問もいくつかあります。
  • キャッシュ制御の厳格な規則とは何ですか？

私自身の質問に答えて戻ると、ここでの主な問題は、すべてが同時に期限切れになることを常に回避する方法です。それが発生することが許可されている場合、システムはキャッシュを再投入する間、速度が低下し、混雑します。

ほとんどの場合、これは実際には問題ではありません。時間の経過とともに、すべてのコンポーネントは、期限切れの時間に関してドリフトする傾向があります。すべてが同時に再構築される複数のコンポーネントがある場合、それらはおそらく単一のコンポーネントとして一緒にキャッシュされる必要があるため、コードのにおいです（たとえば、ページの一意のヘッダー、ボディ、フッターが個別にキャッシュされている場合、おそらくページ自体をキャッシュするだけです）。

キャッシュ全体をクリアしたり、キャッシュキーをローテーションしたりすると、システムの起動後など、一度に多くのものがキャッシュされる必要がある場合があります。この場合、コンポーネントは急速に満杯になり、有効期限は後でバラバラになるため、通常はそれほど悪くありません。

これが問題である限り、いくつかの解決策があります：

• 固定期間ではなく、範囲内のランダムなキャッシュ有効期限を選択するだけです。たとえば、60分ではなく15〜90分のランダムな整数。
• 古い応答を許可します。キャッシュアイテムの有効期限が切れたからといって、キャッシュアイテムがまだ残っている場合にそれを使用できないというわけではありません。ビジネスニーズによっては、有効期限が切れた後に元のバージョンを取得するパフォーマンスの問題がある場合は、それを使用しても問題ありません。HTTPでは、これが「再検証が必要」の目的です（trueの場合、有効期限が切れた後にキャッシュされたバージョンを使用しないことを意味 します）。