Eliminando el almacenamiento en caché en la producción de Rails

Cuando implemento una aplicación de Rails en modo de producción, agrega una cadena de fecha y hora como parámetro de consulta al final de todas las URL de activos estáticos. Esto es para evitar que los navegadores utilicen copias antiguas de los recursos después de que vuelva a desplegar la aplicación.

¿Hay alguna manera de hacer que los Rails usen las antiguas marcas de tiempo para los activos que no han cambiado (y solo los que no han cambiado) desde la última implementación? Quiero hacer esto para evitar que los usuarios tengan que volver a descargar aquellos activos que no han cambiado.

Creo que puedes usar ENV [‘RAILS_ASSET_ID’] para alterar la ID del activo que rompe caché. Desafortunadamente, esto es para todos los activos.

Pero si no está configurado, usa el tiempo de modificación de la fuente del activo. Si ese archivo no se ha modificado desde la última vez que lo usaste, no debería ser un problema.

Si la ID del activo cambia cuando no se han modificado, puede deberse a que su proceso de implementación modifique el tiempo de modificación y quizás pueda ver cómo modificarlo.

Por último, siempre puede anular rails_asset_id con su propio método personalizado .

Espero que esto ayude.

Capistrano, de forma predeterminada, toca todos los archivos que considera un ‘activo’. Como ha dicho, esto significa que después de cada despliegue, los Rails creen que cada activo ha cambiado y los navegadores descargarán una versión más nueva cada vez.

Puede deshabilitar esto en Capistrano con la siguiente configuración

set :normalize_asset_timestamps, false 

Si está usando SVN, las fechas modificadas para sus archivos deben reflejar las fechas en que se modificaron por última vez en su repository, por lo que debe ser perfecto.

Si está utilizando Apache, puede agregar algo como esto para que el almacenamiento en caché realmente funcione. Esto ayuda al decirle al navegador que se base en las directivas de “Control de caché”, lo que significa que si sabe que el activo está almacenado en caché, ni siquiera se molestará en solicitarlo.

 #Etags should be based on the file parameters only (default includes INode) FileETag MTime Size #Rewrite stuff RewriteEngine On #This sets the environment variable (is_versioned) when the URL query string #looks like ?874353948543 or any string of digits RewriteCond %{QUERY_STRING} ^[0-9]+$ RewriteRule ^(.*)$ $1 [env=is_versioned:true]  Options -Indexes FollowSymLinks -MultiViews AllowOverride None Order allow,deny allow from all #For files, force the browser to rely on cache-control directives and #Rails asset timestamps by removing Etags and Last-Modified dates #For all assets that aren't stamped by rails, cache them for ~ 3 hours Header set "Cache-Control" "max-age=10000" Header unset Etag Header unset "Last-Modified" #For all assets that ARE stamped by rails, cache them for 30 days Header set "Cache-Control" "max-age=2592000" env=is_versioned  

He configurado mi servidor de producción de esta manera y ahora los visitantes que regresan solo realizan una solicitud (Obtener /) que devuelve el contenido dynamic y todos los activos (~ 40 – 50) están almacenados en caché.

@Aupajo me gusta esto, pero creo que puedo llevarlo un poco más lejos. El problema aquí es que Capistrano crea nuevas copias de todos los archivos en cada implementación, por lo que se cambian todas las cadenas que destruyen el caché. Sin embargo, un MD5 del archivo solo cambiaría cuando cambie el contenido del archivo.

Por supuesto, generar un MD5 es costoso y lento, pero puede guardar el MD5 de un archivo en memcache, (en función del tiempo de cambio, como si el tiempo hubiera cambiado, el MD5 podría haber cambiado, pero si la marca de tiempo no cambió el MD5 no habrá cambiado

    Intereting Posts