2013-05-24 3 views
20

레일스가 개발 모드에서 느린 것과 비슷한 스레드가 있지만 그 스레드의 솔루션으로 인해 나에게 차이가 없다. 퍼포먼스를 높이고 설정 파일을 망쳐 놓은 보석을 설치하려했지만 성공하지 못했습니다.레일스 개발 서버가 느리고 간단한 페이지를로드하는 데 오랜 시간이 걸린다

저는 레일스에서 ​​시작하기 때문에 약간의 블로그 인 "Getting Started with Rails"가이드에서 시작 응용 프로그램을 실행하고 있습니다. 나는 Ruby 1.9.3과 Rails 3.2.13을 설치했다. OS/X 10.7.5에서 실행됩니다.

사실상 1 줄의 텍스트와 1 줄인 자습서 앱의 시작 페이지를로드 할 때 20-40 초가 소요됩니다. 모든 페이지에 대한 모든 후속 요청에는 20-40 초가 소요됩니다. 그러나 서버 로그를 살펴보면 Rails가하는 일은 오래 걸리는 것 같습니다. 항상 로그를 차지하는 이벤트 사이의 시간입니다. Rails에서 초보자이기 때문에 이것을 디버깅하는 방법을 모릅니다.

예를 들어

: 당신이 볼 수 있듯이

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 

은 초기 GET이 17시 39분 35초에서 시작하고, 레일 밀리 초 (심지어 0 MS 때때로) 대부분의 수백에서 내 모든 것을 처리하지만,있다 각 이벤트 사이의 타임 스탬프가 몇 초씩 올라갑니다. 마지막 이벤트는 초기 GET 후 44 초인 17:40:19에 있습니다. 실제로 그것은 40 초 이상 브라우저에 아무 것도 나타나지 않는다는 것을 의미합니다. Rails의 속도를 높이는 법을 모릅니다. 개발 모드에서도로드하는 데 1 또는 2 개의 모델이 포함 된 간단한 튜토리얼 앱을 사용해야한다고 생각하지 않습니다.

어떤 아이디어를 좁히고이 문제를 해결할 수 있습니까?

참고 : 콘텐츠 길이에 대한 경고는 문제와 관련이 없어야합니다. 나는 Ruby 1.9.3으로 다운 그레이드했을 때 나타난다. 나는 최신 Ruby (2.0.0)를 사용하고 있었지만 느린 Rails 성능의 근원이라고 생각하여 추천 된 Ruby 1.9.3으로 전환했고 처음 경고가 나타났습니다. 그러나 Rails는 dev 모드에서 느리다.

감사합니다, 데이브

업데이트 : 이 문제의 범위를 좁히는 데 도움이, 내가 자산 파이프 라인을 비활성화하고 눈에 띄게 속도 않습니다. 이제는 20-40 대신 4-8 초입니다. 그러나 새로운 오류가 있으며 자산 파이프 라인이 비활성화 된 상태에서 일부 기능이 손실 될 것입니다. 자산 파이프 라인의 속도를 높이고 계속 사용하도록 설정하는 방법이 있습니까?

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 : 이 포스트는 도움 : Diagnosing the cause of slow view rendering

기본적으로,이 지연은 development.rb의 내부 진정한 = config.assets.debug에 의해 발생되고 있었다 끈다. 나는 그것을 틀리게 만들었고 더 빨라 보인다.

레일스 사람들은 디버그를 사용하면 실제로 복잡한 응용 프로그램의 속도가 느려지 겠지만 말 그대로 1 개의 모델/컨트롤러/뷰가있는 간단한 튜토리얼 응용 프로그램이라고 말합니다. 어쨌든, 나는이 성능 향상이 오래 되었으면 좋겠지 만 나의 즉각적인 문제는 해결됩니다.은 "응답되지 않은"필터에서이 문제를 제거하기 위해 의견 (편집 질문 본체)에서 답을 복사

+0

하드 당 대답은 대답. 다른 컴퓨터/브라우저/가상 머신을 사용해 보셨습니까? 다른 버전의 레일즈? Chrome과 같은 개발 도구가 내장 된 브라우저를 사용하고 있습니까? Chrome의 '타임 라인'탭에서 요청을 프로필하고 집안일이 어디에 있는지 확인할 수 있습니다. 'rails-dev-tweaks'와 여러분의 dev 환경이 어떻게 동작 하는지를 수정할 수있는 기타 필수적이지 않은 보석들을 제거하십시오. –

+3

애셋 파이프 라인 (JS/CSS 요청을 처리하는 애셋 파이프 라인)으로 범위를 좁힐 수 있는지 알아 보겠습니다. 'config.assets.enabled = false'를'application.rb'에 추가하고 응답을 확인하십시오. 브라우저는 보통 ''에있는 모든 스크립트/css가로드 될 때까지 페이지를 렌더링하지 않으므로 페이지가 표시되지 않을 수 있습니다. – Subhas

+0

다른 컴퓨터를 사용해 보지 않았습니다. 나는 그것을 시도 할 수있는 윈도우 박스를 가지고 있지만, 나는 Mac에 머물고 싶다. 이걸 이해할 수 없다면 창문을 시험해 볼까합니다. 나는 레일즈 - dev-tweaks를 제거했는데, 어쨌든 차이는 없었습니다. 내 설정은 표준과 동일해야합니다. Chrome 타임 라인을 살펴본 결과 대부분의 시간이 서버의 응답을 기다리고 있습니다. –

답변

25

: 나는 그들이이 게시물 (Diagnosing the cause of slow view rendering)에서 권장하는 어떤 시도

, 및 그것은 효과가 있었다. 애셋 파이프 라인이 활성화되고 페이지로드가 20-40 초에서 1 초 정도가됩니다. 훨씬 더 좋아.

...

기본적으로, 지연이 development.rb 내부 진정한 = config.assets.debug 의한 받고 나온다. 나는 그것을 거짓으로 만들었습니다. 그리고 더 빠를 것 같습니다.

레일즈 사람들은 디버그를 사용하면 실제로는 복잡한 앱이 느려질 것이라고 말합니다. 그러나 이는 문자 그대로 모델/컨트롤러/뷰 1 개가있는 단순한 튜토리얼 앱이었습니다. 어쨌든, 나는이 성능이 의 이익을 얻기를 바랍니다. 그러나 그것은 나의 즉각적인 문제를 해결합니다.

~ Dave Bowman

+0

하지만이 작업도 단점이 있습니까? – Kaspar

+0

@ Kaspar이 기사에 따르면 덜 자세한 오류 메시지가 나타납니다. http://artandlogic.com/2012/12/faster-rails-dev/ – bigtex777

+1

이것은 Rails 3.2에서 앱을 업그레이드 한 후 개발 환경에서 도움이되지 않았습니다 4.2로, development.rb에서'config.assets.digest = false'를 설정하면 트릭이 생겼습니다. – dav1dhunt

관련 문제