Rails-Entwicklungsserver ist langsam und benötigt eine lange Zeit, um eine einfache Seite zu laden

Question

Es gibt ähnliche Threads über Rails, die im Entwicklungsmodus langsam sind, aber keine der Lösungen in diesen Threads hat für mich einen Unterschied gemacht. Ich habe versucht, Edelsteine ​​zu installieren, die die Leistung steigern und mit Konfigurationsdateien herumspielen, aber keinen Erfolg hatten.

Ich beginne gerade mit Rails, und so laufe ich die Startanwendung im "Erste Schritte mit Rails" Guide, der ein kleines Blog ist. Ich habe Ruby 1.9.3 und Rails 3.2.13 wie empfohlen installiert. Ich laufe auf OS/X 10.7.5.

Beim Laden der Startseite der Tutorial-App, die buchstäblich nur aus 1 Textzeile und 1 Link besteht, dauert es 20-40 Sekunden. Jede nachfolgende Anfrage an eine Seite dauert 20-40 Sekunden. Aber wenn ich mir die Server-Logs anschaue, scheint nichts, was Rails macht, lange zu dauern. Es ist die Zeit zwischen den Ereignissen in den Protokollen, die die ganze Zeit in Anspruch nimmt. Als Anfänger in Rails habe ich keine Ahnung, wie man das debuggt.

Zum Beispiel:

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 

Wie Sie bei 17.39.35, die anfänglichen loszulegen sehen können, und Rails verarbeitet alles innerhalb von höchstens hundert Millisekunden (auch 0 ms manchmal), aber die Der Zeitstempel zwischen jedem Ereignis wird um einige Sekunden erhöht. Das letzte Ereignis ist um 17:40:19, was 44 Sekunden nach dem anfänglichen GET ist. In der Praxis bedeutet das, dass über 40 Sekunden lang nichts in meinem Browser angezeigt wird. Ich habe keine Ahnung, wie man Schienen dazu bringt, schneller zu werden. Ich denke nicht, dass es eine einfache Tutorial-App mit 1 oder 2 Modellen braucht, die so lange geladen werden, sogar im Entwicklungsmodus.

Haben Sie Ideen, wie Sie dieses Problem eingrenzen und lösen können?

Hinweis: Die Warnungen zur Inhaltslänge sollten nichts mit dem Problem zu tun haben. Sie erschienen, als ich zu Ruby 1.9.3 herabstufte. Ich benutzte den neuesten Ruby (2.0.0), dachte aber, dass das die Ursache für die langsame Rails-Performance war, also wechselte ich zu dem empfohlenen Ruby 1.9.3 und diese Warnungen erschienen zum ersten Mal. Aber Rails im Dev-Modus ist immer noch langsam.

Danke, Dave

Update: das Problem eingrenzen zu helfen, ich die Asset-Pipeline deaktiviert und es merklich nicht beschleunigen. Es ist jetzt 4-8 Sekunden statt 20-40. Es gibt jedoch neue Fehler, und ich nehme an, dass ich einige Funktionen mit deaktivierter Asset-Pipeline verloren habe. Gibt es eine Möglichkeit, die Asset-Pipeline zu beschleunigen und aktiv zu halten?

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' 

UPDATE: Dieser Beitrag half: Diagnosing the cause of slow view rendering

Im Grunde ist es stellt sich heraus, die Verzögerung durch config.assets.debug verursacht wurde = true innerhalb von development.rb. Ich habe es falsch gemacht und es scheint schneller zu sein.

Die Rails-Jungs sagen, dass das Aktivieren von Debuggen wirklich komplizierte Anwendungen verlangsamen wird, aber das war nur eine einfache Tutorial-App mit buchstäblich 1 Modell/Controller/View. Wie auch immer, ich hoffe, dass diese Leistungsgewinne anhalten, aber es löst mein unmittelbares Problem.

Answer 1

Kopieren der Antwort aus den Kommentaren (und bearbeitet Frage Körper), um diese Frage aus dem „Unbeantwortet“ Filter zu entfernen:

Ich habe versucht, was sie in diesem Beitrag (Diagnosing the cause of slow view rendering) empfohlen, und es funktionierte. Die Asset-Pipeline ist aktiviert, und das Laden der Seite dauert 20 bis 40 Sekunden von bis 1 Sekunde. viel besser zumindest.

...

Grundsätzlich stellt sich die Verzögerung aus wurde durch config.assets.debug = Innenseite development.rb wahr verursacht wird. Ich habe es falsch gemacht und es scheint schneller zu sein.

Die Rails Jungs sagen, dass die Aktivierung von Debug verlangsamen wirklich komplizierte Apps, aber das war nur eine einfache Tutorial App mit buchstäblich 1 Modell/Controller/Ansicht. Wie auch immer, ich hoffe diese Leistung Gewinne, aber es löst mein unmittelbares Problem.

~ Antwort pro Dave Bowman