etags/stale?/fresh_when を使用する利点は何ですか? ページ キャッシングの代わりに (ファイル キャッシュ上で)?
Apache は静的ファイルの etag を自動的に処理しますが、そうでない場合でも、Rails アプリが呼び出されることさえないため、ページ キャッシュの方が優れています。
では、Rails が提供するメソッド (stale?/fresh_when?) をどのような場合に使用しますか?
etags/stale?/fresh_when を使用する利点は何ですか? ページ キャッシングの代わりに (ファイル キャッシュ上で)?
Apache は静的ファイルの etag を自動的に処理しますが、そうでない場合でも、Rails アプリが呼び出されることさえないため、ページ キャッシュの方が優れています。
では、Rails が提供するメソッド (stale?/fresh_when?) をどのような場合に使用しますか?
彼らは本当に無料です。Etags / fresh_whenなどは、ダウンストリームキャッシュ(独自のVarnish/SquidインスタンスやRack::Cache、ブラウザキャッシュ、ISPプロキシサーバーなど)をうまく活用するのに役立ちます。
ページキャッシングは、Apache / Webサーバーがファイルを提供するため、Railsスタックに完全にぶつかるのを防ぎ、DBルックアップは行われません。ただし、キャッシュを最新の状態に保つには、キャッシュの有効期限に対処する必要があります。
etags / conditional getを使用すると、ページで使用されているすべてのレコードを取得する必要があるため、処理時間を大幅に節約できません。
def show
@article = Article.find(params[:id])
@feature = Feature.current
fresh_when :etag => [@article, @feature]
end
ユーザーが現在のページを持っている場合、ページを送信するために必要なレンダリング時間と帯域幅を節約できます。
私が思いついたもう1つの用途は、Railsに「304NotModified」ヘッダーを渡させる前にいくつかの情報を処理できることでした。ページへのヒットを記録したい場合のように。
頭に浮かぶことの 1 つはfresh_when
、ページ キャッシュ全体をクリアした場合でも、レンダリングをいくらか節約できるということです。ここでは、両方をタンデムで使用します。
他の回答も気になります。