Rails-etags対ページキャッシュ（ファイルキャッシュ）

Question

etags / stale？/ fresh_whenを使用する利点は何ですか？ページキャッシュ（ファイルキャッシュ）の代わりに？

Apacheは静的ファイルのetagsを自動的に処理しますが、処理しなかったとしても、Railsアプリは呼び出されないため、ページキャッシングは依然として優れています。

では、どのインスタンスでRailsが提供するメソッド（stale？/ fresh_when？）を使用しますか？

Answer 1

これらは本当に無料です。 Etags / fresh_whenなどは、ダウンストリームキャッシュ（独自のVarnish / Squidインスタンス、Rack :: Cache、ブラウザキャッシュ、またはISPプロキシサーバーなど）でうまくプレイするのに役立ちます

ページキャッシングにより、Apache /ウェブサーバーがファイルを提供するため、レールスタックに完全にアクセスする必要がなくなり、DBルックアップが実行されません。ただし、キャッシュを最新の状態に保つには、キャッシュの有効期限に対処する必要があります。

etags / conditional getを使用すると、ページで使用されているすべてのレコードを取得する必要があるため、処理時間を大幅に節約できません。

def show
  @article = Article.find(params[:id])
  @feature = Feature.current
  fresh_when :etag => [@article, @feature] 
end

ユーザーが現在のページを持っている場合、ページを送信するために必要なレンダリング時間と帯域幅を節約します。

Answer 2

私が思いついたもう1つの用途は、Railsに「304 Not Modified」を渡す前に情報を処理できることです。ヘッダ。ヒットをページに記録する場合のように。

Answer 3

頭に浮かぶことの1つは、ページキャッシュ全体をクリアした場合でも、 fresh_when によってレンダリングがいくらか節約されることです。ここでは、両方を同時に使用します。

他の回答にも興味があります。