11

我在具有 8GB RAM 的 2011 Macbook Pro 上运行 Ruby on Rails。我在没有选项的情况下启动 rails 需要 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 项目做同样的事情(只是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

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

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

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

所以 SDD 减少了 rails 的启动时间将近 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
4

3 回答 3

7

我们可以只分析 rails 引导序列,看看我们是否从中学到了什么。

  • 添加gem 'perftools.rb'到您的 gemfile('.rb' 位不是错字)
  • bundle install
  • 添加require 'perftools'到顶部/environments/development.rb
  • 添加PerfTools::CpuProfiler.start('/tmp/dev_prof')到配置块中development.rb
  • 选择一个您可以在应用程序中轻松访问的网址。在我的例子中,url 是 localhost:3000/games。
  • 找到处理该 url 调用的控制器方法。在我的例子中,它是 GamesController 中的 index 方法。
  • 添加require 'perftools'到 GamesController 的顶部
  • 添加PerfTools::CpuProfiler.stop到 GamesController 的 index 方法中。

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

  • 一旦加载了rails,就去访问localhost:3000/games,这会导致分析器写入/tmp/dev_prof。
  • 导航到 /tmp 文件夹并运行 'pprof.rb --tex /tmp/dev_prof | 较少的'

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

  • 运行“导出 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
于 2013-02-03T21:54:07.093 回答
2

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

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

于 2013-01-28T17:46:11.527 回答
1

可能是因为您在开发环境中运行 rails。在这里查看开发和生产之间的一些区别 - Rails 的开发和生产环境之间有什么重要的区别?

于 2013-01-28T13:25:41.740 回答