Raíles 3: acelerar el tiempo de carga de la consola

Question

Me pregunto si hay alguna manera relativamente fácil de acelerar el tiempo de carga de la consola, que está comenzando a acercarse a 30 segundos. Tengo muchas subclases cuyos métodos no parecen verse afectados por reload!, así que termino abriendo y cerrando la consola mucho. IRB carga un rayo rápido.

¿Tengo demasiadas gemas? ¿Cómo hago para cronometrar las tareas de carga para poder ver lo que más tiempo me toma? Como puede ver, ya he probado la gema dev-boost en vano. La aplicación está bien en Passenger, es solo la carga de la consola lo que me saca de quicio. Ejecutando en MBP OSX 10.6.6 con 2.4GHz y 4GB de RAM. No usando RVM.

Versiones:

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

memoria:

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 

Muchas gracias!

Answer 1

Solo puedo sugerir poner tu bata de laboratorio y dividir el problema. Vea si comentar todos sus requisitos de gemas acelera las cosas (presumiblemente eso también implicará comentar las piezas de código que se basan en esas gemas). Si es así, comente la mitad a la vez y así sucesivamente.

Disculpa, pero esta no es una respuesta real. Podrías probar ruby-prof, supongo, por ejemplo invocando con rails runner y un script no-op.

me trataron ruby-prof script/rails runner 'nil' en mi mac pero parece tener acaba de estrellarse :-)

EDITAR

Si está utilizando git para su aplicación puede probar que es la bisectriz de comandos también y ver si hay un punto específico en el tiempo cuando las cosas se pusieron lentas, en lugar de simplemente hinchazón general.

Answer 2

¡Recargar! ha sido un problema desde hace algún tiempo. Eche un vistazo al this. Hay algunos parches que puede usar y algunos consejos sobre cómo puede solucionar su problema.

El método de recarga en sí tiene este aspecto.

# reloads the environment 
def reload!(print=true) 
    puts "Reloading..." if print 
    ActionDispatch::Callbacks.new(lambda {}, false).call({}) 
    true 
end 

Siempre puede agregar su entorno a este método para anular su función y forzar la recarga que requiera.

Esto me ha funcionado, háganos saber si le conviene. Todo lo mejor.

Answer 3

Finalmente encontré mis cuellos de botella de inicio usando Benchmark. En particular, vaya a la joya bundler y en lib/bundler/runtime.rb, busque la línea que hace Kernel.require y lo envuelve como esto:

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

Es posible que tenga que añadir require 'referente' en algún lugar de su aplicación, como en config/boot.rb. Eso le mostrará cuánto tiempo lleva requerir cada gema. No puedo garantizar que sus resultados coincidan con los míos, pero tenía algunas gemas que tardaban más de un segundo en cargarse en comparación con el milisegundo inferior para la mayoría.Algunas eran gemas que no necesitaba para desarrollando pero sí necesitaba algunas tareas en el entorno de desarrollo, p. capistrano, shoulda. Hice una evaluación comparativa de otras áreas de inicio (inicializadores, etc.), pero no pude encontrar ningún cuello de botella significativo.

Aún no he encontrado una forma clara de configurar la aplicación para que solo cargue aquellas para las tareas donde realmente se necesitan. Posiblemente, podría crear un entorno llamado: speedy y usar RAILS_ENV = speedy rails s/c para el inicio cuando sé que no necesito esas gemas. Luego, en Gemfile, podría usar group: speedy para excluir esas gemas en ciertos casos.

Dicho todo esto, la mayor molestia de inicio para mí es tener que cargar todo el entorno para ejecutar una tarea de rake. Probablemente podría excluir la mayoría de las gemas por eso, pero Gemfile comenzaría a complicarse, así que no sé si vale la pena.

Answer 4

Puede acelerarlo agregando: require => nil a las entradas lentas de Gemfile y solicítelas manualmente. p.

gem 'jammit', :require => nil 

También resolví este problema en una reunión que tuve. Esto parece ser un error en Ruby 1.9.2 (véanse los comentarios de este parche: https://gist.github.com/1008945)

se puede arreglar por parchear el 1.9.2 por la esencia Acabo de vincular o actualizar a 1.9.2-head o 1.9.3-head.

Answer 5

ligeramente adaptada forma que es copia-pastable, envuelve todo requiere, y proporciona una salida sortable:

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

A continuación, se puede ejecutar sin-op para verlos:

rails runner 1 

O ordenarlos y mostrar la parte superior 50:

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

Answer 6

Este es, sin duda sobre la limpieza de su código y la identificación de los cuellos de botella , pero una vez que haya hecho esos ahorros, vale la pena mirar algo como Zeus para acelerar sus tiempos de desarrollo.

gem install zeus 

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

¡No es, sin errores y que a veces requieren un reinicio, pero todavía estoy viendo un aumento general en los tiempos de desarrollo de servidor rápido y la consola se reinicia después de los cambios de código pequeñas.