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

时间:2013-01-28 12:58:47

标签: ruby-on-rails-3 performance

我正在使用8GB内存的2011 Macbook Pro上运行Ruby on Rails。我花了2秒钟没有选项启动rails,加载控制台需要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

3 个答案:

答案 0 :(得分:5)

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

  • gem 'perftools.rb'添加到您的gem文件中('。rb'位不是拼写错误)
  • 运行bundle install
  • require 'perftools'添加到/environments/development.rb
  • 的顶部
  • PerfTools::CpuProfiler.start('/tmp/dev_prof')添加到development.rb
  • 中的配置块
  • 选择您可以在应用中轻松访问的网址。在我的情况下,网址是localhost:3000 / games。
  • 找到处理该url调用的控制器方法。在我的例子中,它是GamesController中的索引方法。
  • require 'perftools'添加到GamesController的顶部
  • PerfTools::CpuProfiler.stop添加到GamesController的索引方法。

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

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

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

  • 运行'export RUBY_GC_MALLOC_LIMIT = 60000000'
  • 运行'export 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

答案 1 :(得分:2)

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

对我而言,它已将时间减少到秒(3/4)以加载环境。希望它可以帮到你

答案 2 :(得分:1)

可能是因为您在开发环境中运行rails。在此处查看开发和生产之间的一些差异 - What important differences are there between Rails' development and production environments?