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

Question

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

我刚开始使用 Rails，所以我正在运行“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 个模型的简单教程应用程序不应该这么长时间，即使在开发模式下也是如此。

有什么想法可以缩小和解决这个问题吗？

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

谢谢， 戴夫

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

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'

更新: 这篇文章帮助:Diagnosing the cause of slow view rendering

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

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

Answer 1

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

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.

~ 根据 Dave Bowman 回答