Rails 3 - accélérer les Temps de Chargement de la Console

Question

Je me demandais si il n'y a aucun moyen relativement simple pour accélérer ma console de temps de chargement, qui est de commencer à l'approche de 30 secondes. J'ai beaucoup de sous-classes dont les méthodes ne semblent pas être affectés par reload! donc j'arrive à la fin de l'ouverture et de la fermeture de la console de beaucoup. RIR des charges de la vitesse de l'éclair.

Puis-je avoir trop de gemmes? Comment puis-je aller sur le timing de la charge des tâches afin que je puisse voir ce qui prend le plus de temps? Comme vous pouvez le voir, j'ai déjà essayé la dev-boost gem en vain. L'application est très bien pour les Passagers, c'est juste la console de chargement que les bugs de la merde hors de moi. En cours d'exécution sur MBP OSX 10.6.6 avec de 2,4 GHz et de 4 go de RAM. Ne pas utiliser RVM.

Versions:

Ovid$ rails -v
Rails 3.0.3
Ovid$ ruby -v
ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10]

Mémoire:

Ovid$ vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                         118818.
Pages active:                       341320.
Pages inactive:                      99490.
Pages speculative:                  310576.
Pages wired down:                   112527.
"Translation faults":             23097323.
Pages copy-on-write:               1270961.
Pages zero filled:                13836659.
Pages reactivated:                      36.
Pageins:                            165761.
Pageouts:                                0.
Object cache: 28 hits of 760846 lookups (0% hit rate)

Gemfile:

source 'http://rubygems.org'

gem 'rails', '3.0.3'
gem 'mysql2'
gem 'foreigner'
gem 'haml'
gem 'capistrano'
gem 'nokogiri'

#web services
gem 'yammer4r'
gem 'ruby-freshbooks'

#authentication gems from nifty generator
gem "bcrypt-ruby", :require => "bcrypt"
gem "mocha", :group => :test
gem 'authlogic'

#dev
group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git', :require => 'rails_development_boost'
end

#testing
group :test do
  gem 'database_cleaner'
  gem 'cucumber-rails'
  gem 'cucumber'
  gem 'rspec-rails'
  gem 'spork'
  gem 'launchy'
  gem 'machinist'
  gem 'faker'
  gem 'capybara'
end

Merci beaucoup!

Answer 1

J'ai enfin trouvé mon démarrage des goulots d'étranglement à l'aide de l'indice de Référence. En particulier, accédez à la bundler gem et dans lib/bundler/runtime.rb, trouver la ligne qui n'Noyau.besoin et l'envelopper comme ceci:

puts Benchmark.measure("require #{file}") {
  Kernel.require file
}.format("%n: %t %r")

Vous pouvez avoir à ajouter exiger "de référence" quelque part dans votre application, comme dans config/boot.rb. Qui va vous montrer combien de temps il faut pour exiger de chaque bijou. Je ne peux pas garantir les résultats correspondent à la mienne, mais j'ai eu quelques perles qui ont été prise au cours d'une seconde pour charger comparé avec le sous-ordre de la milliseconde pour la plupart. Quelques-uns étaient des gemmes que je n'ai pas besoin de développer , mais je n'ai besoin de certaines tâches dans l'environnement de développement, par exemple, capistrano, shoulda. Je comparés à d'autres zones de démarrage (initialiseurs, etc), mais ne pouvais pas trouver toutes les goulets d'étranglement importants.

Je n'ai pas encore trouvé un moyen propre à configurer l'application pour charger seulement ceux pour les tâches où ils sont vraiment nécessaires. Éventuellement, je pourrais créer un environnement appelé :rapide et l'utilisation RAILS_ENV=speedy rails s/c pour le démarrage quand je sais que je n'ai pas besoin de ces gemmes. Puis dans le Gemfile, je pouvais utiliser du groupe :rapide pour exclure ces joyaux dans certains cas.

Cela dit, le plus gros démarrage de l'agacement pour moi est d'avoir à charger la totalité de l'environnement pour exécuter une tâche rake. Je pourrais probablement exclure la plupart des pierres précieuses, mais Gemfile serait de commencer à déraper, donc je ne sais pas si ça vaut le coup.

Answer 2

Légèrement adapté la forme qui est la copie pastable, enveloppe tout le nécessite, et fournit triable de sortie:

# Add this to the top of boot.rb
require 'benchmark'
def require(file)
  puts Benchmark.measure("") {
    super
  }.format("%t require #{file}")
end

Ensuite, vous pouvez exécuter no-op, pour les voir:

rails runner 1

Ou de les trier et d'afficher le top 50:

rails runner 1 | sort -nr | head -n 50

Answer 3

Vous pouvez l'accélérer en ajoutant :exiger => nil à la lenteur de la Gemfile entrées et nécessitent manuellement. par exemple

gem 'jammit', :require => nil

J'ai également abordé cette question dans une rencontre que j'ai eu. Cela semble être un bug dans ruby 1.9.2 (voir les commentaires de ce patch: https://gist.github.com/1008945)

Vous pouvez résoudre le problème en corrigeant votre 1.9.2 par l'essentiel, j'ai juste lié ou la mise à niveau 1.9.2-head ou 1.9.3-head.

Answer 4

C'est certainement sur le nettoyage de votre code et d'identifier les goulots d'étranglement, mais une fois que vous avez fait ces économies, il vaut la peine de regarder quelque chose comme Zeus pour accélérer votre dev fois.

gem install zeus

https://github.com/burke/zeus (docs)

Il n'est pas sans bugs et n'a parfois besoin d'un redémarrage, mais je suis toujours de voir une augmentation globale du temps de développement rapide des serveur et la console redémarre après de petites modifications de code.

Answer 5

Je ne peux que suggérer de mettre sur votre manteau de laboratoire et coupant la question. Voir si en commentant tous vos gem exigences de la vitesse (sans doute ça aussi impliquer en commentant les morceaux de code qui s'appuient sur les gemmes). Si oui, commentez la moitié à la fois et ainsi de suite.

Désolé, ce n'est pas une vraie réponse.. Vous pouvez essayer de ruby-prof, je suppose, par exemple en invoquant il avec rails runner et un no-op script.

J'ai essayé d' ruby-prof script/rails runner 'nil' sur mon mac, mais il semble que l'ont vient de tomber en panne :-)

MODIFIER

Si vous utilisez git pour votre application, vous pouvez essayer de la traversent, commande trop et voir si il y a un point spécifique dans le temps quand les choses se sont lents, plutôt que de simplement en général le ballonnement.