Ruby-on-rails Rails 开发服务器很慢，加载一个简单的页面需要很长时间

Rails development server is slow and takes a long time to load a simple page

提问by Dave Bowman

There are similar threads about Rails being slow in development mode, but none of the solutions in those threads has made any difference for me. I've tried installing gems that boost performance and mucking around with config files, but have had no success.

有关于 Rails 在开发模式下缓慢的类似线程，但这些线程中的任何解决方案都没有对我产生任何影响。我试过安装可提高性能并处理配置文件的 gem，但没有成功。

I'm just starting with Rails, and so I'm running the startup application in the "Getting Started with Rails" guide, which is a little blog. I've installed Ruby 1.9.3 and Rails 3.2.13, as recommended. I'm running on OS/X 10.7.5.

我刚开始使用 Rails，所以我正在运行“Rails 入门”指南中的启动应用程序，这是一个小博客。我已经按照推荐安装了 Ruby 1.9.3 和 Rails 3.2.13。我在 OS/X 10.7.5 上运行。

When loading the start page of the tutorial app, which is literally just 1 line of text and 1 link, it takes 20-40 seconds. Every subsequent request to any page take 20-40 seconds. However, when I take a look at the server logs, nothing that Rails is doing seems to be taking long. It's the time in-between the events in the logs that is taking up all the time. Being a beginner in Rails I have no idea how to debug this.

当加载教程应用程序的起始页面时，它实际上只是 1 行文本和 1 个链接，需要 20-40 秒。对任何页面的每个后续请求都需要 20-40 秒。但是，当我查看服务器日志时，Rails 所做的任何事情似乎都没有花费很长时间。日志中的事件之间的时间一直在占用。作为 Rails 的初学者，我不知道如何调试它。

For example:

例如：

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

As you can see, the initial GET started at 17:39:35, and Rails is processing everything within at most hundreds of milliseconds (even 0 ms sometimes), but the timestamp between each event goes up by several seconds. The last event is at 17:40:19, which is 44 seconds after the initial GET. In practice, that means nothing shows up in my browser for over 40 seconds. I have no idea how to get Rails to speed up. I don't think it should take a simple tutorial app with 1 or 2 models this long to load, even in development mode.

如您所见，初始 GET 开始于 17:39:35，Rails 在最多数百毫秒（有时甚至 0 毫秒）内处理所有内容，但每个事件之间的时间戳会增加几秒。最后一个事件发生在 17:40:19，即初始 GET 后 44 秒。实际上，这意味着我的浏览器中超过 40 秒没有显示任何内容。我不知道如何让 Rails 加速。我认为即使在开发模式下也不应该需要一个简单的教程应用程序来加载 1 或 2 个模型这么长的时间。

Any ideas how to narrow down and solve this problem?

任何想法如何缩小和解决这个问题？

Note: the warnings about content-length should have nothing to do with the issue. They appeared when I downgraded to Ruby 1.9.3. I was using the latest Ruby (2.0.0), but thought that that was the source of the slow Rails performance so I switched to the recommended Ruby 1.9.3 and those warnings appeared for the first time. But Rails in dev mode is stil slow.

注意：关于内容长度的警告应该与问题无关。当我降级到 Ruby 1.9.3 时，它们出现了。我使用的是最新的 Ruby (2.0.0)，但认为这是 Rails 性能缓慢的根源，所以我切换到推荐的 Ruby 1.9.3，这些警告第一次出现。但是开发模式下的 Rails 仍然很慢。

Thanks, Dave

谢谢，戴夫

Update: To help narrow down the issue, I disabled the asset pipeline and it does speed up noticeably. It's now 4-8 seconds instead of 20-40 However there are new errors, and I suppose I lose some functionality with the asset pipeline disabled. Is there a way to speed up the asset pipeline and keep it enabled?

更新：为了帮助缩小问题的范围，我禁用了资产管道，它确实显着加快了速度。现在是 4-8 秒而不是 20-40 但是有新的错误，我想我在禁用资产管道的情况下失去了一些功能。有没有办法加快资产管道并使其保持启用状态？

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: This post helped: Diagnosing the cause of slow view rendering

更新：这篇文章有帮助：诊断视图渲染缓慢的原因

Basically, it turns out the delay was being caused by config.assets.debug = true inside of development.rb. I made it false and it seems to be faster.

基本上，事实证明延迟是由 development.rb 中的 config.assets.debug = true 引起的。我把它弄错了，它似乎更快。

The Rails guys say that enabling debug will slow down really complicated apps, but this was just a simple tutorial app with literally 1 model/controller/view. Anyways, I hope these performance gains last, but it does solve my immediate problem.

Rails 的人说启用调试会减慢非常复杂的应用程序的速度，但这只是一个简单的教程应用程序，实际上只有 1 个模型/控制器/视图。无论如何，我希望这些性能提升能够持续下去，但它确实解决了我眼前的问题。

回答by DreadPirateShawn

Copying the answer from the comments (and edited question body) in order to remove this question from the "Unanswered" filter:

从评论（和编辑过的问题正文）中复制答案，以便从“未回答”过滤器中删除此问题：

I tried what they recommended in this post (Diagnosing the cause of slow view rendering), and it worked. Asset pipeline is enabled, and page loading goes from 20-40 seconds to like 1 second. much better at least.

...

Basically, it turns out the delay was being caused by config.assets.debug = true inside of development.rb. I made it false and it seems to be faster.

The Rails guys say that enabling debug will slow down really complicated apps, but this was just a simple tutorial app with literally 1 model/controller/view. Anyways, I hope these performance gains last, but it does solve my immediate problem.

我尝试了他们在这篇文章中推荐的内容（诊断视图渲染缓慢的原因），并且奏效了。资产管道已启用，页面加载时间从 20-40 秒变为 1 秒。至少好多了。

...

基本上，事实证明延迟是由 development.rb 中的 config.assets.debug = true 引起的。我把它弄错了，它似乎更快。

Rails 的人说启用调试会减慢非常复杂的应用程序的速度，但这只是一个简单的教程应用程序，实际上只有 1 个模型/控制器/视图。无论如何，我希望这些性能提升能够持续下去，但它确实解决了我眼前的问题。

~ answer per Dave Bowman

~ 回答每个戴夫鲍曼