Serwer rozwoju Railsów jest powolny i zajmuje dużo czasu, aby załadować prostą stronę

Question

Istnieją podobne wątki dotyczące Railsów, które są wolne w trybie programowania, ale żadne z rozwiązań w tych wątkach nie zrobiło dla mnie żadnej różnicy. Próbowałem instalować klejnoty, które zwiększają wydajność i fałszują pliki konfiguracyjne, ale nie odniosły sukcesu.

Właśnie zaczynam od Rails, więc uruchamiam aplikację startową w przewodniku "Getting Started with Rails", który jest małym blogiem. Zainstalowałem Ruby 1.9.3 i Rails 3.2.13, zgodnie z zaleceniami. Używam systemu OS/X 10.7.5.

Podczas ładowania strony startowej aplikacji samouczka, która jest dosłownie tylko 1 wierszem tekstu i 1 linkiem, zajmuje to 20-40 sekund. Każde kolejne żądanie dowolnej strony trwa 20-40 sekund. Jednakże, gdy przyjrzę się dziennikom serwera, nic, co Railsy nie robi, wydaje się trwać długo. To czas pomiędzy zdarzeniami w dziennikach, który zajmuje cały czas. Będąc początkującym w Railsach nie mam pojęcia, jak to debugować.

Na przykład:

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 

Jak widać, początkowa zacząć na 17:39:35 i Rails przetwarza wszystko w ciągu najwyżej kilkuset milisekund (ms czasami nawet 0), ale znacznik czasu między poszczególnymi zdarzeniami wzrasta o kilka sekund. Ostatnie wydarzenie to 17:40:19, czyli 44 sekundy po początkowym GET. W praktyce oznacza to, że nic nie wyświetla się w mojej przeglądarce przez ponad 40 sekund. Nie mam pojęcia, jak przyspieszyć działanie Railsów. Nie sądzę, że powinno to zająć prostą aplikację samouczków z 1 lub 2 modelami tak długo, aby załadować, nawet w trybie programistycznym.

Jakieś pomysły, jak zawęzić i rozwiązać ten problem?

Uwaga: ostrzeżenia o długości treści nie powinny mieć nic wspólnego z problemem. Pojawiły się, gdy obniżyłem poziom do Ruby 1.9.3. Używałem najnowszej Ruby (2.0.0), ale myślałem, że to jest źródło powolnego działania Railsów, więc przełączyłem się na zalecaną Ruby 1.9.3 i te ostrzeżenia pojawiły się po raz pierwszy. Ale Rails w trybie dewelopera jest wolny.

Dzięki Dave

Aktualizacja: Aby zawęzić problem, ja wyłączone rurociągu aktywów i to nie przyspieszy znacząco. Teraz jest 4-8 sekund zamiast 20-40 Jednak pojawiają się nowe błędy i przypuszczam, że tracę pewną funkcjonalność z wyłączonym potokiem zasobów. Czy istnieje sposób na przyspieszenie potoku aktywów i utrzymanie go w stanie aktywnym?

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: Ten post pomógł: Diagnosing the cause of slow view rendering

Zasadniczo, to okazuje się, że zwłoka była spowodowana config.assets.debug = true wewnątrz development.rb. Zrobiłem to fałszywym i wydaje się, że jest szybciej.

Użytkownicy Railsów mówią, że włączenie debugowania spowolni naprawdę skomplikowane aplikacje, ale była to prosta aplikacja samouczka z dosłownie 1 modelem/kontrolerem/widokiem. W każdym razie, mam nadzieję, że te przyrosty wydajności będą trwały, ale rozwiązuje to mój natychmiastowy problem.

Answer 1

Kopiowanie odpowiedź od komentarzach (i edytowane ciała zapytania), aby usunąć to pytanie z „Nieodebrane” Filtr:

starałem co zalecane w tym poście (Diagnosing the cause of slow view rendering) i zadziałało. Przewód z aktywami jest włączony, a ładowanie strony idzie od 20-40 sekund, aby polubić 1 sekundę. znacznie lepiej.

...

Zasadniczo, to okazuje się, że zwłoka była spowodowana config.assets.debug = true wewnątrz development.rb. Zrobiłem to fałszywie i wydaje się być szybsze.

Użytkownicy Railsów twierdzą, że włączenie debugowania spowolni naprawdę skomplikowane aplikacje, ale jest to prosta samouczka z dosłownie 1 model/kontroler/widok. W każdym razie, mam nadzieję, że te wyniki zyskają na końcu, ale to rozwiązuje mój natychmiastowy problem.

~ odpowiedź za Dave Bowman