为什么Ruby on Rails需要这么长时间才能启动



我在2011年Macbook Pro上运行Ruby on Rails,具有8GB RAM。我需要 2 秒来启动没有选项的导轨,加载控制台需要 12 秒。Rails在这段时间里在做什么?我简直不敢相信它需要 12 秒。我的应用程序不是那么大——app文件夹中有 10,607 行。

$ time rails > /dev/null
real    0m2.830s
user    0m2.751s
sys 0m0.076s
$ time echo exit | rails console > /dev/null
real    0m12.825s
user    0m11.779s
sys 0m0.898s

我正在运行Ruby 1.9.3和Rails 3.2:

$ ruby -v
ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin12.0.0]
$ rails -v
Rails 3.2.11
$ wc -l `find app -name *.rb`
10607 total

编辑:

对空轨道项目做同样的事情(只是rails new):

marc@menasor ~/dev/rails_empty $ time rails > /dev/null
real    0m2.192s
marc@menasor ~/dev/rails_empty $ time echo exit | rails c > /dev/null
real    0m3.807s

因此,启动一个空轨项目需要将近 4 秒。这 4 秒发生了什么?

以下是在带有4GB RAM的SSD的Macbook Air上启动我的原始Rails项目的一些时间。

$ time rails
real    0m1.161s
$ time echo exit | rails console
real    0m20.356s

所以SDD减少的rail启动时间接近2秒,所以我假设这是做很多IO。不过,启动 rails 控制台的时间已经增加。

编辑:

在 Reck 的建议后添加分析数据:

Total: 404 samples
 116  28.7%  28.7%      116  28.7% garbage_collector
  62  15.3%  44.1%      258  63.9% Kernel#require
  12   3.0%  47.0%       28   6.9% Journey::Visitors::Each#visit
  12   3.0%  50.0%       12   3.0% Regexp#===
   9   2.2%  52.2%       52  12.9% Module#class_eval
   9   2.2%  54.5%       12   3.0% Module#module_eval
   9   2.2%  56.7%        9   2.2% Module#remove_method
   8   2.0%  58.7%        9   2.2% Module#enable
   7   1.7%  60.4%       24   5.9% Journey::Visitors::Visitor#visit
   6   1.5%  61.9%      255  63.1% Kernel#tap
   5   1.2%  63.1%      237  58.7% BasicObject#instance_exec
   5   1.2%  64.4%        5   1.2% Psych::Nodes::Scalar#initialize
   4   1.0%  65.3%        8   2.0% Array#uniq
   4   1.0%  66.3%       11   2.7% Enumerable#inject
   4   1.0%  67.3%       71  17.6% Kernel#load
   4   1.0%  68.3%       61  15.1% Kernel.load

我们可以分析轨道引导顺序,看看我们是否从中学到了什么。

  • gem 'perftools.rb'添加到您的 gemfile(".rb"位不是拼写错误)
  • 运行bundle install
  • require 'perftools'添加到/environments/development.rb顶部
  • PerfTools::CpuProfiler.start('/tmp/dev_prof')添加到 development.rb 中的配置块
  • 选择一个可在应用中轻松访问的 URL。在我的情况下,网址是本地主机:3000/游戏。
  • 查找处理该 URL 调用的控制器方法。就我而言,它是GamesController中的index方法。
  • require 'perftools'添加到游戏控制器的顶部
  • PerfTools::CpuProfiler.stop添加到游戏控制器的索引方法。

现在用"rails s"启动 rails 开发环境。

  • 加载 Rails 后,请访问 localhost:3000/games,这会导致分析器写入/tmp/dev_prof。
  • 导航到/tmp 文件夹并运行"pprof.rb --tex/tmp/dev_prof | less"
顶部的呼叫

是占用最多时间的呼叫。您可能会注意到垃圾收集器占用了相当多的时间。幸运的是,我们可以改善这一点:

  • 运行"导出RUBY_GC_MALLOC_LIMIT=60000000"
  • 运行"导出RUBY_FREE_MIN=200000"

当您重新执行分析时,垃圾回收器现在占用的时间应该少得多。有关其他信息,请参阅 http://whalesalad.com/posts/reduce-rails-boot-time-by-30-40-percent。

Before:
  82  35.8%  35.8%       82  35.8% garbage_collector
  30  13.1%  48.9%      131  57.2% Kernel#require
   9   3.9%  52.8%        9   3.9% Regexp#===
   6   2.6%  55.5%       25  10.9% Module#class_eval
   5   2.2%  57.6%        8   3.5% Module#module_eval
   4   1.7%  59.4%        9   3.9% Journey::Visitors::Visitor#visit
   4   1.7%  61.1%      129  56.3% Kernel#tap
   4   1.7%  62.9%       33  14.4% Kernel.load
   4   1.7%  64.6%        4   1.7% Module#enable
   3   1.3%  65.9%        3   1.3% Enumerable#any?
   3   1.3%  67.2%       20   8.7% EventMachine.run_machine
After:
  33  18.1%  18.1%       33  18.1% garbage_collector
  31  17.0%  35.2%      137  75.3% Kernel#require
   5   2.7%  37.9%        6   3.3% Module#enable
   5   2.7%  40.7%        6   3.3% Module#module_eval
   5   2.7%  43.4%        5   2.7% Regexp#===
   4   2.2%  45.6%      125  68.7% BasicObject#instance_exec
   4   2.2%  47.8%       20  11.0% EventMachine.run_machine

我遇到了同样的问题,虽然我的笔记本电脑已经使用了 4 年,只有 4gb RAM,但是我现在正在使用这个:https://github.com/thedarkone/rails-dev-boost

对我来说,它将加载环境的时间缩短到几秒钟(3/4)。希望对您有所帮助

可能是

因为你在开发环境中运行轨道。在这里查看开发和生产之间的一些差异 - Rails 的开发和生产环境之间有什么重要区别?

相关内容

  • 没有找到相关文章