Rails serveur de développement est lent et prend beaucoup de temps pour charger une page simple
Il existe des discussions similaires sur le fait que Rails soit lent en mode développement, mais aucune des solutions de ces threads n'a fait de différence pour moi. J'ai essayé d'installer des gemmes qui améliorent les performances et de nettoyer les fichiers de configuration, mais sans succès.
Je ne fais que commencer avec Rails, et j'exécute donc l'application de démarrage dans le guide "Getting Started with Rails", qui est un petit blog. J'ai installé Ruby 1.9.3 et Rails 3.2.13, comme recommandé. J'exécute sur OS/X 10.7.5.
Lors du chargement de la page de démarrage de l'application du didacticiel, qui n'est littéralement qu'une ligne de texte et un lien, cela prend 20 à 40 secondes. Chaque demande ultérieure à n'importe quelle page prend 20 à 40 secondes. Cependant, quand je jette un œil aux journaux du serveur, rien de ce que Rails ne semble prendre de temps. C'est le temps entre les événements dans les journaux qui prend tout le temps. Étant un débutant dans Rails, je n'ai aucune idée de comment déboguer cela.
Par exemple:
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
Comme vous pouvez le voir, le GET initial a commencé à 17:39:35 et Rails traite tout en quelques centaines de millisecondes (parfois même 0 ms parfois), mais l'horodatage entre chaque événement augmente de plusieurs secondes. Le dernier événement est à 17:40:19, soit 44 secondes après le GET initial. En pratique, cela signifie que rien ne s'affiche dans mon navigateur pendant plus de 40 secondes. Je ne sais pas comment accélérer Rails. Je ne pense pas que cela devrait prendre une application de didacticiel simple avec 1 ou 2 modèles aussi longs à charger, même en mode développement.
Des idées sur la façon de réduire et de résoudre ce problème?
Remarque: les avertissements concernant la longueur du contenu ne devraient avoir rien à voir avec le problème. Ils sont apparus lorsque j'ai rétrogradé à Ruby 1.9.3. J'utilisais la dernière Ruby (2.0.0), mais je pensais que c'était la source des performances lentes Rails, j'ai donc basculé vers la version recommandée Ruby 1.9.3 et ces avertissements sont apparus pour la première fois. Mais Rails en mode dev est toujours lent.
Merci, Dave
Mise à jour: Pour aider à réduire le problème, j'ai désactivé le pipeline d'actifs et il s'accélère sensiblement. Il est maintenant de 4 à 8 secondes au lieu de 20 à 40. Cependant, de nouvelles erreurs se produisent et je suppose que je perds certaines fonctionnalités avec le pipeline d'actifs désactivé. Existe-t-il un moyen d'accélérer le pipeline d'actifs et de le garder activé?
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'
MISE À JOUR: Ce message a aidé: Diagnostiquer la cause du rendu de vue lente
Fondamentalement, il s'avère que le retard était causé par config.assets.debug = true à l'intérieur de development.rb. Je l'ai rendu faux et cela semble être plus rapide.
Les gars de Rails disent que l'activation du débogage ralentira les applications vraiment compliquées, mais ce n'était qu'une simple application de didacticiel avec littéralement 1 modèle/contrôleur/vue. Quoi qu'il en soit, j'espère que ces gains de performances dureront, mais cela résout mon problème immédiat.
Copie de la réponse des commentaires (et du corps de la question modifiée) afin de supprimer cette question du filtre "Sans réponse":
J'ai essayé ce qu'ils recommandaient dans ce post ( Diagnostiquer la cause du rendu de vue lente ), et cela a fonctionné. Le pipeline d'actifs est activé et le chargement des pages passe de 20 à 40 secondes à 1 seconde. beaucoup mieux au moins.
...
Fondamentalement, il s'avère que le retard était causé par config.assets.debug = true à l'intérieur de development.rb. Je l'ai rendu faux et cela semble être plus rapide.
Les gars de Rails disent que l'activation du débogage ralentira les applications vraiment compliquées, mais ce n'était qu'un simple didacticiel avec littéralement 1 modèle/contrôleur/vue. Quoi qu'il en soit, j'espère que ces gains de performances dureront, mais cela résout mon problème immédiat.
~ réponse par Dave Bowman