【问题标题】:Rails development server is slow and takes a long time to load a simple pageRails 开发服务器速度慢,加载简单页面需要很长时间
【发布时间】:2013-05-20 14:30:31
【问题描述】:

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

我刚刚开始使用 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 仍然很慢。

谢谢, 戴夫

更新: 为了帮助缩小问题范围,我禁用了资产管道,它确实显着加快了速度。现在是 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

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

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

【问题讨论】:

  • 很难说。您是否尝试过不同的机器/浏览器/虚拟机?不同版本的 Rails?您是否使用带有内置开发工具的浏览器,例如 Chrome?在 Chrome 的“时间轴”选项卡中,您可以分析请求并查看阻塞的位置。尝试删除 rails-dev-tweaks 和任何其他可能会修改您的开发环境行为方式的非必要 gem。
  • 让我们看看是否可以将其缩小到资产管道(服务于 JS/CSS 请求的管道)。将config.assets.enabled = false 添加到application.rb 并检查响应。浏览器通常不会渲染页面,直到 <head> 中的所有脚本/css 都加载完毕,因此这可能是您看不到页面的原因。
  • 没有试过其他机器。我确实有一个可以试用的 windows 盒子,但我更愿意留在 Mac 上。如果我无法解决这个问题,也许我会尝试 Windows。我删除了 rails-dev-tweaks 因为它没有任何区别。我的设置应该与它们一样标准。我查看了 Chrome 时间线,发现它大部分时间都在等待来自服务器的响应。
  • 我禁用了资产管道,它确实加快了速度。现在大约是 4-8 秒,而不是 20-40 秒。但是当资产管道被禁用时,我也会收到新的错误。将使用输出更新我的帖子。
  • 我尝试了他们在这篇文章 (stackoverflow.com/questions/15317048/…) 中推荐的方法,并且成功了。资产管道已启用,页面加载时间从 20-40 秒缩短到 1 秒。至少好多了。

标签: ruby-on-rails ruby performance


【解决方案1】:

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

我尝试了他们在这篇文章中推荐的内容 (Diagnosing the cause of slow view rendering), 它奏效了。资产管道已启用,页面加载从 20-40秒喜欢1秒。至少好多了。

...

基本上,事实证明延迟是由 config.assets.debug = true 在 development.rb 中。我把它弄错了 而且似乎更快。

Rails 的人说启用调试真的会变慢 复杂的应用程序,但这只是一个简单的教程应用程序 字面意思是 1 个模型/控制器/视图。无论如何,我希望这些表现 最后的收获,但它确实解决了我眼前的问题。

~回答Dave Bowman

【讨论】:

  • 但是这样做也有缺点吗?
  • @Kaspar 根据这篇文章,您会收到不太详细的错误消息:artandlogic.com/2012/12/faster-rails-dev
  • 在将应用程序从 Rails 3.2 升级到 4.2 后,这对我的开发环境没有帮助,但是在 development.rb 中设置 config.assets.digest = false 就可以了。
  • 以上方法在 Windows 上都不适合我。
【解决方案2】:

还有一些重要的考虑因素。


如果您有缓存设置但凭据不正确(或者像我一样已经更新),那么 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
end

Rails 将尝试连接到您在 development.rb 配置文件中配置的任何缓存。

如果失败(大约 20 秒的尝试),它将放弃尝试连接到缓存本身并处理数据本身(就像缓存已过期一样)

tldr:如果您有缓存设置,请确保您的凭据是最新的,并且您可以建立连接。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-05-15
    相关资源
    最近更新 更多