我在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 的开发和生产环境之间有什么重要区别?