web-dev-qa-db-ja.com

Rails開発サーバーは低速で、シンプルなページのロードに時間がかかります

Railsが開発モードで遅いことについて同様のスレッドがありますが、それらのスレッドのソリューションはどれも私にとって違いはありません。パフォーマンスを向上させ、設定ファイルをいじり回すgemをインストールしようとしましたが、成功していません。

私はRailsから始めたばかりなので、ちょっとしたブログである「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に開始し、Railsは最大で数百ミリ秒（場合によっては0ミリ秒）ですべてを処理していますが、各イベント間のタイムスタンプは数秒上がります。最後のイベントは17:40:19で、最初のGETから44秒後です。実際には、40秒以上ブラウザに何も表示されません。 Railsを高速化する方法がわかりません。開発モードであっても、ロードするのにこれほど長いモデルが1つまたは2つのシンプルなチュートリアルアプリにかかるとは思わない。

この問題を絞り込んで解決する方法はありますか？

注：content-lengthに関する警告は、問題とは関係ありません。 Ruby 1.9.3にダウングレードしたときに表示されました。私は最新のRuby（2.0.0）を使用していましたが、それが遅いRailsパフォーマンスの原因だと思ったため、推奨されるRuby 1.9.3に切り替えて、それらの警告が表示されました初めて。しかし、開発モードのRailsはまだ遅いです。

ありがとう、デイブ

更新：問題を絞り込むために、アセットパイプラインを無効にしました。これにより、速度が著しく向上しました。現在は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'

更新：この投稿は役に立ちました： 遅いビューレンダリングの原因の診断

基本的に、development.rb内でconfig.assets.debug = trueが原因で遅延が発生したことがわかります。私はそれを偽にしたが、それはより速いようだ。

Railsの人たちは、デバッグを有効にすると本当に複雑なアプリが遅くなると言いますが、これは文字通り1つのモデル/コントローラー/ビューを備えた単純なチュートリアルアプリでした。とにかく、これらのパフォーマンスの向上が最後まで続くことを願っていますが、それは私の差し迫った問題を解決します。

ruby-on-railsrubyperformance
29
Dave Bowman

この質問を「未回答」フィルターから削除するために、コメント（および編集された質問本文）から回答をコピーします。

私は彼らがこの投稿で推奨することを試みました（ 遅いビューレンダリングの原因の診断 ）、そしてそれはうまくいきました。アセットパイプラインが有効になり、ページの読み込みが20〜40秒から1秒程度になります。少なくともはるかに良い。

...

基本的に、development.rb内でconfig.assets.debug = trueが原因で遅延が発生したことがわかります。私はそれを偽りにして、それはより速いようです。

Railsデバッグを有効にすると本当に複雑なアプリが遅くなると言いますが、これは文字通り1つのモデル/コントローラー/ビューを備えた単純なチュートリアルアプリでした。それは私の差し迫った問題を解決します。

〜回答 Dave Bowman

41
DreadPirateShawn