rails 3.1 - ¿Forzar los activos de desarrollo para que se publiquen como estaban en 3.0.x?

Question

Estoy en el proceso de actualización de una aplicación. Actualmente 3.1.rc8.

El problema es que, en desarrollo, en cada solicitud, parece que cada recurso se ejecuta en la pila de rieles. Estamos hablando de cada archivo de imagen, js y css (y hay muchos de ellos). Después de la primera solicitud, todos devuelven 304, pero todavía ES TAN LENTO.

Hay un montón de esto después de cada solicitud:

Started GET "/assets/jquery-ui-1.8.16.custom.css?body=1" for 127.0.0.1 at 2011-08-30 15:36:21 -0400 
Served asset /jquery-ui-1.8.16.custom.css - 304 Not Modified (0ms) 

Started GET "/assets/yui.css?body=1" for 127.0.0.1 at 2011-08-30 15:36:21 -0400 
Served asset /yui.css - 304 Not Modified (0ms) 

¿Cómo puedo hacer que los activos, en el desarrollo solamente, hasta que nos sirvieran como los de antes en 3.0.x?

También estoy usando estas etiquetas para evitar que mis css/js de ser compilado en un único archivo en dev:

= stylesheet_link_tag 'application', :debug => Rails.env.development? 
= javascript_include_tag 'application', :debug => Rails.env.development? 

Aquí está mi application.rb

require File.expand_path('../boot', __FILE__) 

require 'rails/all' 

if defined?(Bundler) 
    Bundler.require(:default, :assets, Rails.env) 
end 

module Fooapp 
    class Application < Rails::Application 
    config.encoding = "utf-8" 

    config.filter_parameters += [:password, :password_confirmation] 

    config.assets.enabled = true 

    config.assets.version = '1.0' 
    end 
end 

y development.rb:

Fooapp::Application.configure do 

    config.cache_classes = false 

    config.whiny_nils = true 

    config.consider_all_requests_local  = true 
    config.action_controller.perform_caching = false 

    config.action_mailer.raise_delivery_errors = true 

    config.active_support.deprecation = :log 

    config.action_dispatch.best_standards_support = :builtin 

    config.assets.compress = false 

    config.assets.debug = true 
end 

Answer 1

La lentitud que he visto es principalmente relacionados con el pensamiento esfinge (que está en mi Gemfile). En desarrollo, TS carga algunas cosas relacionadas con I18n en cada solicitud de página ... y cada activo se considera una solicitud de página.

https://github.com/freelancing-god/thinking-sphinx/blob/v2.0.7/lib/thinking_sphinx/railtie.rb#L29

De todas formas, el mantenedor del TS es consciente, adn ese archivo ya no existe en maestro. Hasta que se realice una nueva versión, puede comentar esas dos líneas I18n localmente.

Answer 2

Rails está ejecutando todos los enganches to_prepare en cada solicitud de activos de Sprockets, y hay un buen número de gemas que realizan una gran cantidad de trabajo en sus ganchos. (Rails es un delincuente indirecto, también, ya que está recargando parte del código en cada solicitud de activos)

En lugar de esperar a que optimicen sus ganchos de precarga (en general, o solo para solicitudes de activos), echa un vistazo al https://github.com/wavii/rails-dev-tweaks. Deshabilita los ganchos de precarga (incluida la recarga de código) durante las solicitudes de activos.

También es configurable para cualquier otro tipo de solicitud que desee