2011-09-24 21 views
25

Polecenie "aktywa rake: precompile" działa bardzo wolno dla mnie. Zwłaszcza na moim serwerze produkcyjnym Amazon EC2 Micro, który nie ma wielu zasobów procesora. W EC2 muszę czekać 1 minutę lub dłużej podczas każdego wdrożenia tylko dla tego zadania prekompilacji. Czy istnieje sposób na przyspieszenie?atuty rake: prekompilacja jest powolna

Wcześniej używałam Jammita do kompresji/minifikacji css i js. Jammit pracował prawie 10 razy szybciej na tej samej stronie i serwerach.

+2

możesz wstępnie skompilować swoje aktywa przed wdrożeniem –

+1

Dobra, myślałem o tym. Ale nie wiem, jak łatwo wdrożyć prekompilowane zasoby do produkcji. Używam capistrano i za każdym razem, gdy skończę wstępne skompilowanie aktywów. Obawiam się, że repozytorium git będzie szybko rosło w tym przypadku, zachowując historię wszystkich poprzednich zasobów. I to nie jest tylko css/js - ale także wszystkie obrazy zasobów. – Evgenii

+2

Dla mnie też jest bardzo powolny (135 987ms = ~ 2 minuty). Muszę przyjrzeć się wstępnemu kompilacji przed wdrożeniem ... Obawiam się, że dodam je również do git, głównie dlatego, że dodałoby to sporo hałasu do dzienników git. Nie polecałbym dodawać ich do git - wystarczy zsynchronizować ten katalog z localhost z serwerem internetowym jako częścią skryptu cap caploy. –

Odpowiedz

30

Jeśli nie trzeba ładować środowisko Rails, które należy wyłączyć z:

config.assets.initialize_on_precompile = false 

EDIT: Właśnie napisał gem aby rozwiązać ten problem, zwany turbo-sprockets-rails3. Przyspiesza to twoją assets:precompile tylko przez rekompilację zmienionych plików i kompilowanie tylko raz, aby wygenerować wszystkie zasoby.

Byłoby świetnie, gdybyś pomógł mi przetestować klejnot turbo-sprockets-rails3 i daj mi znać, jeśli masz jakiekolwiek problemy.

+3

Twój klejnot jest niesamowity.Rozwiązałem mój problem z d3 i wstępną kompilacją. Dzięki – chaostheory

10

Istnieje bug in Rails 3.1.0, który zawiera zbyt wiele plików w procesie prekompilacji. Może to być powód spowolnienia, jeśli masz wiele aktywów js i css.

Drugi to to, że Sprockets (klejnot robi kompilację) jest bardziej złożony i musi pozwalać na więcej opcji - scss, coffeescript i erb. Z tego powodu podejrzewam, że będzie wolniej robić tylko konkatenację i zminimalizowanie.

Zgodnie z sugestią, można wstępnie skompilować pliki przed wdrożeniem, jeśli problem nadal występuje.

+0

Dziękuję za wyjaśnienie. Myślę też, że jest powolny, ponieważ musi załadować środowisko railsowe do produkcji, co nie miało miejsca w przypadku Jammit. W każdym razie nie wrócę do Jammit. Bardzo podoba mi się potok aktywów. – Evgenii

1

Moje rozwiązanie polega na wykluczeniu z prekompilacji aplikacji .css i wszelkich innych zasobów związanych z aplikacją. Dzięki temu mogę jednorazowo użyć rake assets:precompile, aby wstępnie skompilować zasoby związane z silnikiem.

Następnie na każdym wdrożeniu używam proste zadanie natarcia budować żadnych aktywów aplikacyjnych związanych i połączyć je w manifest.yml:

namespace :assets do 
    task :precompile_application_only => :environment do 
    require 'sprockets' 

    # workaround used also by native assets:precompile:all to load sprockets hooks 
    _ = ActionView::Base 

    # ============================================== 
    # = Read configuration from Rails/assets.yml = 
    # ============================================== 

    env   = Rails.application.assets 
    target  = File.join(::Rails.public_path, Rails.application.config.assets.prefix) 
    assets  = YAML.load_file(Rails.root.join('config', 'assets.yml')) 
    manifest_path = Rails.root.join(target, 'manifest.yml') 
    digest  = !!Rails.application.config.assets.digest 
    manifest  = digest 


    # ======================= 
    # = Old manifest backup = 
    # ======================= 

    manifest_old = File.exists?(manifest_path) ? YAML.load_file(manifest_path) : {} 

    # ================== 
    # = Compile assets = 
    # ================== 

    compiler = Sprockets::StaticCompiler.new(env, 
              target, 
              assets, 
              :digest => digest, 
              :manifest => manifest) 
    compiler.compile 

    # =================================== 
    # = Merge new manifest into old one = 
    # =================================== 

    manifest_new = File.exists?(manifest_path) ? YAML.load_file(manifest_path) : {} 

    File.open(manifest_path, 'w') do |out| 
     YAML.dump(manifest_old.merge(manifest_new), out) 
    end 

    end 
end 

Aby określić, które aktywa kompilacji używam plik konfiguracyjny YAML (config/assets.yml):

np.

--- 
- site/site.css 
- admin/admin.css 
- site/site.js 
- admin/admin.js 
Powiązane problemy