開発モードで Rails が遅いという同様のスレッドがありますが、それらのスレッドの解決策はどれも私にとって何の違いもありませんでした。パフォーマンスを向上させる宝石をインストールし、構成ファイルをいじってみましたが、成功しませんでした。
私は 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 ミリ秒) 以内に処理していますが、各イベント間のタイムスタンプは数秒ずつ上がっています。最後のイベントは、最初の GET から 44 秒後の 17:40:19 です。実際には、これはブラウザに 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 つのモデル/コントローラー/ビューを備えた単純なチュートリアル アプリにすぎません。とにかく、これらのパフォーマンスの向上が続くことを願っていますが、当面の問題は解決します.