Rails开发服务器速度慢，加载简单页面需要很长时间。
在开发模式中，Rails也有类似的线程，但是这些线程中的任何解决方案都没有对我产生任何影响。我尝试过安装gems来提高性能，并在配置文件中到处乱跑，但都没有成功。
我只是从Rails开始，所以我在“开始使用Rails”指南中运行启动应用程序，这是一个小博客。我按照建议安装了Ruby1.9.3和Rails 3.2.13。我在OS/X10.7.5上运行。
当加载教程应用程序的起始页面时，它实际上只是一行文本和一个链接，它需要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，也就是第一次比赛结束后的44秒。在实践中，这意味着在我的浏览器中超过40秒什么都不会出现。我不知道如何让铁轨加速。我不认为一个简单的教程应用程序有1或2个模型这么长时间来加载，即使在开发模式。
有什么办法缩小范围，解决这个问题吗？
注意:关于内容长度的警告应该与问题无关。当我降级到Ruby1.9.3时，它们就出现了。我使用的是最新的Ruby (2.0.0)，但我认为这是Rails性能缓慢的原因，所以我转而使用推荐的Ruby1.9.3，并首次出现了这些警告。但是开发模式下的Rails仍然很慢。
谢谢，戴夫
更新:为了缩小问题范围，我禁用了资产管道，它确实明显地加快了速度。现在是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'更新:这篇文章帮助了：Diagnosing the cause of slow view rendering
基本上，结果显示延迟是由config.assets.debug = true在development.rb内部造成的。我把它弄错了，而且看起来更快。
Rails的人说，启用调试会减慢非常复杂的应用程序，但这只是一个简单的教程应用程序，实际上有一个模型/控制器/视图。无论如何，我希望这些表现能持续下去，但它确实解决了我眼前的问题。
回答 2
Stack Overflow用户
发布于 2013-10-08 04:50:34
复制注释(和编辑的问题正文)中的答案，以便从“未回答”筛选器中删除此问题：
我尝试了他们在这篇文章(Diagnosing the cause of slow view rendering)中推荐的内容，结果成功了。启用了资产管道，页面加载从20-40秒一直持续到1秒。至少好多了。 ..。 基本上，结果显示延迟是由config.assets.debug = true在development.rb内部造成的。我把它弄错了，而且看起来更快。 Rails的人说，启用调试会减慢非常复杂的应用程序，但这只是一个简单的教程应用程序，实际上有一个模型/控制器/视图。无论如何，我希望这些表现能持续下去，但它确实解决了我眼前的问题。
每个Dave Bowman的答案
Stack Overflow用户
发布于 2021-03-06 13:20:35
还有一些重要的事情要考虑。
如果您有缓存设置，但是凭据不正确(或者已经像我一样被更新了)，那么Rails将尝试在放弃并手动处理数据之前几次连接到服务器。
例如，在这个块中
@data = Rails.cache.fetch('all_market_data', expires_in: 1.hour) do
Model.all.where(x: y).order('value ASC').each do |c|
# functionality
# proccessing
# etc
end
@data
endRails将尝试连接到development.rb配置文件中配置的任何缓存。
失败后(大约20秒的尝试)，它将放弃连接到缓存本身并处理数据本身的尝试(就像缓存上的过期已被满足一样)。
tldr:如果您有缓存设置，请确保您的凭据是最新的，并且可以建立一个连接.。
https://stackoverflow.com/questions/16744279
复制相似问题
腾讯云开发者
