Rieles: etags frente a almacenamiento en caché de página (caché de archivos)

Question

¿Cuáles serían algunas de las ventajas de usar etags / stale? / fresh_when? en lugar de almacenamiento en caché de página (en un caché de archivos)?

Apache maneja automáticamente los etags para archivos estáticos, pero incluso si no lo hiciera, el almacenamiento en caché de la página aún sería mejor ya que la aplicación Rails ni siquiera recibe llamadas.

Entonces, ¿en qué casos usaría los métodos proporcionados por Rails (rancio? / fresh_when?)?

Answer 1

Son realmente complementarios. Etags / fresh_when etc. le ayudan a jugar bien con cachés posteriores (como sus propias instancias de Varnish / Squid o Rack :: Cache o el caché del navegador o los servidores proxy ISP ...)

El almacenamiento en caché de la página le evita golpear su pila de rieles por completo porque Apache / su servidor web sirven el archivo, por lo que no se realizan búsquedas de DB. Pero debe lidiar con la caducidad de la memoria caché para mantenerla fresca.

Usando etags / conditional get, no ahorra mucho tiempo de procesamiento ya que aún necesita obtener todos los registros utilizados en la página:

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

en el caso de que el usuario tenga una página actual, le ahorra algo de tiempo de representación y el ancho de banda requerido para enviar la página.

Answer 2

Otro uso que se me ocurrió fue que aún podía procesar cierta información antes de dejar que Rails distribuyera el "304 no modificado". encabezamiento. Por ejemplo, si desea grabar visitas a una página.

Answer 3

Una cosa que me viene a la mente es que fresh_when aún le ahorrará algo de representación, incluso si borró toda la caché de la página. Aquí estaría usando ambos en tándem.

Tengo curiosidad por otras respuestas también.