Rails - etags vs. page caching (cache dei file)

Question

Quali sarebbero alcuni vantaggi dell'utilizzo di etags / stale? / fresh_when? invece della cache della pagina (su una cache di file)?

Apache gestisce automaticamente gli etags per i file statici, ma anche in caso contrario, la memorizzazione nella cache della pagina sarebbe comunque migliore poiché l'app Rails non viene nemmeno chiamata.

Quindi, in quali casi dovrei usare i metodi forniti da Rails (stantio? / fresh_when?)?

Answer 1

Sono davvero gratuiti. Etags / fresh_when ecc. Ti aiutano a giocare bene con le cache a valle (come le tue istanze Varnish / Squid o Rack :: Cache o la cache del browser o i server proxy ISP & # 8230;)

La memorizzazione nella cache della pagina ti evita di colpire completamente lo stack delle tue rotaie perché Apache / il tuo server web servono il file, quindi non vengono eseguite ricerche DB. Ma devi gestire la scadenza della cache per mantenere la cache aggiornata.

Usando etags / get condizionale, non si risparmia molto tempo di elaborazione poiché è ancora necessario ottenere tutti i record utilizzati nella pagina:

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

nel caso in cui l'utente abbia una pagina corrente, consente di risparmiare un po 'di tempo di rendering e la larghezza di banda necessaria per inviare la pagina.

Answer 2

Un altro uso che mi è venuto in mente è stato che potevi ancora elaborare alcune informazioni prima di lasciare che Rails distribuisse il "304 Not Modified" intestazione. Ad esempio, se desideri registrare hit su una pagina.

Answer 3

Una cosa che viene in mente è che fresh_when ti farà comunque risparmiare un po 'di rendering anche se hai cancellato l'intera cache della pagina. Qui useresti entrambi in tandem.

Sono curioso anche di altre risposte.