ruby on rails - mundo - El servidor de desarrollo de Rails es lento y lleva mucho tiempo cargar una página simple
ruby on rails hola mundo (1)
Copiando la respuesta de los comentarios (y el cuerpo de la pregunta editada) para eliminar esta pregunta del filtro "Sin respuesta":
Intenté lo que recomendaron en esta publicación ( Diagnóstico de la causa de la representación de vista lenta ) y funcionó. La canalización de activos está habilitada y la carga de la página va de 20 a 40 segundos a 1 segundo. Mucho mejor al menos.
...
Básicamente, resulta que el retraso fue causado por config.assets.debug = true dentro de development.rb. Lo hice falso y parece ser más rápido.
Los muchachos de Rails dicen que habilitar la depuración ralentizará las aplicaciones realmente complicadas, pero esto fue solo una aplicación tutorial simple con literalmente 1 modelo / controlador / vista. De todos modos, espero que estas ganancias de rendimiento sean duraderas, pero resuelve mi problema inmediato.
~ respuesta por
Hay hilos similares sobre Rails que son lentos en el modo de desarrollo, pero ninguna de las soluciones en esos hilos ha hecho ninguna diferencia para mí. He intentado instalar gemas que aumentan el rendimiento y me metí en los archivos de configuración, pero no he tenido éxito.
Estoy empezando con Rails, así que estoy ejecutando la aplicación de inicio en la guía "Cómo comenzar con Rails", que es un pequeño blog. He instalado Ruby 1.9.3 y Rails 3.2.13, como se recomienda. Estoy corriendo en OS / X 10.7.5.
Al cargar la página de inicio de la aplicación del tutorial, que es literalmente solo 1 línea de texto y 1 enlace, toma entre 20 y 40 segundos. Cada solicitud posterior a cualquier página tardará 20-40 segundos. Sin embargo, cuando miro los registros del servidor, nada de lo que hace Rails parece tardar mucho. Es el tiempo intermedio entre los eventos en los registros que está ocupando todo el tiempo. Siendo un principiante en Rails, no tengo idea de cómo depurar esto.
Por ejemplo:
Started GET "/posts/1" for 127.0.0.1 at 2013-05-24 17:39:35 -0400
Processing by PostsController#show as HTML
Parameters: {"id"=>"1"}
Post Load (36.9ms) SELECT "posts".* FROM "posts" WHERE "posts"."id" = ? LIMIT 1 [["id", "1"]]
Comment Load (24.3ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1
Rendered comments/_comment.html.erb (0.9ms)
Rendered comments/_form.html.erb (25.8ms)
Rendered posts/show.html.erb within layouts/application (158.5ms)
Completed 200 OK in 274ms (Views: 201.0ms | ActiveRecord: 61.9ms)
Started GET "/assets/home.css?body=1" for 127.0.0.1 at 2013-05-24 17:39:52 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /home.css - 304 Not Modified (0ms)
[2013-05-24 17:39:52] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Started GET "/assets/posts.css?body=1" for 127.0.0.1 at 2013-05-24 17:40:09 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /posts.css - 304 Not Modified (0ms)
[2013-05-24 17:40:09] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:12 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /jquery.js - 304 Not Modified (0ms)
[2013-05-24 17:40:12] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Started GET "/assets/scaffolds.css?body=1" for 127.0.0.1 at 2013-05-24 17:40:16 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /scaffolds.css - 304 Not Modified (0ms)
[2013-05-24 17:40:16] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Started GET "/assets/jquery_ujs.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:19 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /jquery_ujs.js - 304 Not Modified (0ms)
[2013-05-24 17:40:19] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Started GET "/assets/home.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:21 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /home.js - 304 Not Modified (0ms)
[2013-05-24 17:40:21] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Como puede ver, el GET inicial comenzó a las 17:39:35, y Rails está procesando todo en un máximo de cientos de milisegundos (incluso 0 ms a veces), pero la marca de tiempo entre cada evento aumenta varios segundos. El último evento es a las 17:40:19, 44 segundos después del GET inicial. En la práctica, eso significa que nada aparece en mi navegador durante más de 40 segundos. No tengo idea de cómo hacer que Rails se acelere. No creo que deba tomar una aplicación de tutorial simple con 1 o 2 modelos de tiempo de carga, incluso en el modo de desarrollo.
¿Alguna idea de cómo reducir y resolver este problema?
Nota: las advertencias sobre la longitud del contenido no deben tener nada que ver con el problema. Aparecieron cuando bajé de categoría a Ruby 1.9.3. Estaba usando el último Ruby (2.0.0), pero pensé que esa era la fuente del lento rendimiento de Rails, así que cambié al Ruby 1.9.3 recomendado y esas advertencias aparecieron por primera vez. Pero los rieles en modo dev son muy lentos.
Gracias Dave
Actualización: Para ayudar a reducir el problema, deshabilité la canalización de activos y se acelera notablemente. Ahora es de 4 a 8 segundos en lugar de 20 a 40. Sin embargo, hay nuevos errores y supongo que pierdo algunas funciones con el flujo de activos deshabilitado. ¿Hay alguna manera de acelerar el flujo de activos y mantenerlo habilitado?
ActionController::RoutingError (No route matches [GET] "/stylesheets/application.css"):
actionpack (3.2.13) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call''
actionpack (3.2.13) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call''
railties (3.2.13) lib/rails/rack/logger.rb:32:in `call_app''
railties (3.2.13) lib/rails/rack/logger.rb:16:in `block in call''
activesupport (3.2.13) lib/active_support/tagged_logging.rb:22:in `tagged''
railties (3.2.13) lib/rails/rack/logger.rb:16:in `call''
actionpack (3.2.13) lib/action_dispatch/middleware/request_id.rb:22:in `call''
rack (1.4.5) lib/rack/methodoverride.rb:21:in `call''
rack (1.4.5) lib/rack/runtime.rb:17:in `call''
activesupport (3.2.13) lib/active_support/cache/strategy/local_cache.rb:72:in `call''
rack (1.4.5) lib/rack/lock.rb:15:in `call''
actionpack (3.2.13) lib/action_dispatch/middleware/static.rb:63:in `call''
railties (3.2.13) lib/rails/engine.rb:479:in `call''
railties (3.2.13) lib/rails/application.rb:223:in `call''
rack (1.4.5) lib/rack/content_length.rb:14:in `call''
railties (3.2.13) lib/rails/rack/log_tailer.rb:17:in `call''
rack (1.4.5) lib/rack/handler/webrick.rb:59:in `service''
/Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/httpserver.rb:138:in `service''
/Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/httpserver.rb:94:in `run''
/Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/server.rb:191:in `block in start_thread''
ACTUALIZACIÓN: esta publicación ayudó a: diagnosticar la causa de la visualización lenta
Básicamente, resulta que el retraso fue causado por config.assets.debug = true dentro de development.rb. Lo hice falso y parece ser más rápido.
Los muchachos de Rails dicen que habilitar la depuración ralentizará las aplicaciones realmente complicadas, pero esto fue solo una aplicación tutorial simple con literalmente 1 modelo / controlador / vista. De todos modos, espero que estas ganancias de rendimiento sean duraderas, pero resuelve mi problema inmediato.