đường ray 3.1 - lực lượng phát triển tài sản để được phục vụ như họ đang ở trong 3.0.x?

Question

Tôi đang trong quá trình nâng cấp ứng dụng. Hiện tại là 3.1.rc8.

Vấn đề là, trong phát triển, theo mọi yêu cầu, có vẻ như mọi tài sản đều được chạy qua ngăn xếp đường ray. Chúng tôi đang nói chuyện, mỗi hình ảnh, js và css tập tin (Và có rất nhiều người trong số họ). Sau yêu cầu đầu tiên, tất cả đều trả về 304, nhưng nó vẫn là SO SLOW.

Có rất nhiều toàn bộ này sau mỗi lần yêu cầu:

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) 

Làm thế nào tôi có thể làm cho tài sản, phát triển duy nhất, được phục vụ lên như họ sử dụng để ở 3.0.x?

Tôi cũng đang sử dụng các thẻ để ngăn chặn css của tôi/js từ được biên soạn thành một tập tin duy nhất trong dev:

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

Dưới đây là application.rb tôi

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 

và 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

Sự chậm chạp mà tôi đã thấy chủ yếu liên quan đến tư tưởng nhân sư (trong Gemfile của tôi). Trong quá trình phát triển, TS tải một số thứ liên quan đến I18n trên mỗi yêu cầu trang .. và mỗi nội dung được coi là một yêu cầu trang.

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

Anyways, nhà duy trì của TS là nhận thức, adn tập tin đó không còn tồn tại trên tổng thể. Cho đến khi một bản phát hành mới được thực hiện, bạn chỉ có thể nhận xét hai dòng I18n đó tại địa phương.

Answer 2

Rails đang chạy tất cả các móc to_prepare trên mọi yêu cầu nội dung Sprockets - và có một số lượng lớn đá quý thực hiện một lượng lớn công việc trong móc của chúng. (Rails tự nó là một người phạm tội gián tiếp, quá, vì nó tải lại một số mã của bạn trên mỗi yêu cầu tài sản, quá)

Thay vì chờ đợi cho họ để tối ưu hóa móc tải trước của họ (nói chung, hoặc chỉ cho yêu cầu tài sản), hãy xem https://github.com/wavii/rails-dev-tweaks. Nó vô hiệu hóa các móc tải trước (bao gồm tải lại mã) trong các yêu cầu nội dung.

Nó cũng có thể định cấu hình cho bất kỳ loại yêu cầu nào khác mà bạn muốn