rieles de activos de almacenamiento en caché rompe primeras pocas cargas de la página

Question

Estamos utilizando el almacenamiento en caché activo Carriles por JS y CSS como esto:

<%= stylesheet_link_tag 'reset','global','admins','autocomplete', 'date_input', 'tablesorter', 'partners', 'jqmodal', :media => 'screen', :cache => set_asset_cache(:admins) %> 
<%= javascript_include_tag :defaults, 'autocomplete', 'searchbox', 'jqmodal', :cache => set_asset_cache(:admins) %> 

En nuestro despliegue que llamar rake tmp:assets:clear cada vez. El problema es que las primeras páginas que se cargan después de una implementación aparecen sin css o js en la página. Supongo hasta que todos los.js y all.css almacenados en caché se hayan regenerado.

Nos implementamos muchas veces al día y esto es aterrador para cualquier usuario que se encuentre con una página reventada.

¿Han encontrado las personas alguna manera de suavizar esto para que los nuevos activos almacenados en caché estén garantizados en la primera carga de la nueva página?

Answer 1

La gema AssetHat soluciona este problema exacto. En lugar de concatenar activos la primera vez que se carga una página (lo que aumenta el tiempo de carga de esa página), concatena los activos en la implementación en su lugar. Como extra, la gema también minimiza su CSS y JS, lo que ahorra bytes preciosos.

Después de la configuración, el uso es bastante simple:

• Uso include_css :bundle => 'admins' y include_js :bundle => 'admins' en su diseño. (Los contenidos del paquete se configuran en un archivo de configuración para mantener el diseño ligero).
• Agregue rake asset_hat:minify a su secuencia de comandos de implementación. Mi compañía lo ha usado en producción con Capistrano desde hace aproximadamente un año.

Hay más información en el readme y docs, y yo estaría feliz de escuchar cualquier preguntas/ideas!

Answer 2

usted podría intentar el calentamiento de la caché durante el despliegue utilizando wget, como un ejemplo (shamelessly reposted):

wget -r -nd --delete-after http://whatever.com/~popular/page/ 

Sin embargo, esto tendría que ser ejecutado después de cambiar el enlace simbólico a su nuevo despliegue. Una solución posiblemente más elegante podría ser llamar manualmente a los métodos de caché de activos en su implementación, aunque no estoy seguro de qué tan factible sea. Here's where the caching is performed in Rails:

# File vendor/rails/actionpack/lib/action_view/helpers/asset_tag_helper.rb, line  273 
273:  def javascript_include_tag(*sources) 
274:   options = sources.extract_options!.stringify_keys 
275:   concat = options.delete("concat") 
276:   cache = concat || options.delete("cache") 
277:   recursive = options.delete("recursive") 
278: 
279:   if concat || (ActionController::Base.perform_caching && cache) 
280:   joined_javascript_name = (cache == true ? "all" : cache) + ".js" 
281:   joined_javascript_path = File.join(joined_javascript_name[/^#{File::SEPARATOR}/] ? ASSETS_DIR : JAVASCRIPTS_DIR, joined_javascript_name) 
282: 
283:   unless ActionController::Base.perform_caching && File.exists?(joined_javascript_path) 
284:    write_asset_file_contents(joined_javascript_path, compute_javascript_paths(sources, recursive)) 
285:   end 
286:   javascript_src_tag(joined_javascript_name, options) 
287:   else 
288:   expand_javascript_sources(sources, recursive).collect { |source| javascript_src_tag(source, options) }.join("\n") 
289:   end 
290:  end 

Usted puede ser capaz de modificar el código de almacenamiento en caché y ejecutarlo manualmente en despliegue.