Rails 扯 Rails 开发环境暴慢的原因

huacnlee · 2011年11月25日 · 最后由 yakjuly 回复于 2012年02月04日 · 5918 次阅读

当然,这时 Mac 环境,配置也很不错 在我的一些相对功能较多的项目中,每次页面请求都很慢 (500ms - 1.5s+),大家的什么情况? 哪怕是一些仅仅只有一两个数据查询的页面 但是如果把 config/environments/development.rb 里面的 config.cache_classes 打开

config.cache_classes = true 

速度立马就上去了。 刚才我又测试了一下,用的 Mongoid 每增加一个 Model 的查询就会多处 100ms 以上 users_controller.rb

def index
    Topic.find_by_id(1)
    Post.find_by_id(1)
    Favorite.find_by_id(1)
    Ask.find_by_id(1)
    TaskWork.find_by_id(1)
    Message.find_by_id(1)
end
Started GET "/" for 127.0.0.1 at 2011-11-25 16:05:20 +0800
  Processing by HomeController#index as HTML
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['topics'].find({:deleted_at=>nil, :_id=>1}).limit(-1)
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['posts'].find({:deleted_at=>nil, :_id=>1}).limit(-1)
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['favorites'].find({:_id=>1}).limit(-1)
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['asks'].find({:deleted_at=>nil, :_id=>1}).limit(-1)
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['task_works'].find({:_id=>1}).limit(-1)
MONGODB made_dev['system.namespaces'].find({})
MONGODB made_dev['messages'].find({:_id=>1}).limit(-1).sort([[:_id, :desc]])
Rendered home/_base.html.erb (0.6ms)
Rendered home/index.html.erb (1.1ms)
Completed 200 OK in 721ms (Views: 4.3ms)

@xdite 说他们没有这样的情况,很好奇大家的状况如何? 记得有一次杭州 Ruby Tuesday 也讨论过这个话题,于是有了 rails-dev-boost 这个解决方案... 但是,实际使用中发现,rails-dev-boost 会引出很多问题,这个很麻烦,比如 Model 的代码更新无法重载了,必须重启 Rails ...

因为每次请求之前把代码都重载了一遍,和 rails 相比,sinatra-reloader 只重载变化的文件就非常快... 有个 gem 可以在请求之前重载代码,可能会快点...

我觉得还好阿,其实 rails 3.1 慢主要原因是因为每一个 asset 文件都要重载 rails 的程序文件的关系,包括图片在内都会,你装下这个 gem gem 'rails-dev-tweaks', '~> 0.5.1' , :group => :development 这个 gem 使请求 asset 和 xhr 的时候不重新加载程序文件,兼容性也不错,没有 rails-dev-boost 导致的问题 它的主要原理是跳过 asset 和 xhr 的 reload 操作,只有读取 html 内容的时候才会进行 reload 具体的加速策略是可配置的

简单的可以用 EventMachine 的 watch 来监控文件变化并 reload

你们不用其他的方式,会上什么样子?

顶一下,没人对这个话题感兴趣?

我有兴趣,关注解决办法。

#3 楼 @aNdReW_Qx 慢主要原因是因为每一个asset文件都要重载rails的程序文件的关系,包括图片在内都会 可否详细点,我不知道。:P ,以前不是这样的么? *= require_tree . 这个去掉就不会都加 载了。然后按需进行对每个页面的 js 加载。还有不是要开启 asset 吗。把 cache_classes 开启我感觉快很多了。

#8 楼 @Ddl1st 因为 3.1 加了 pipline 的关系以前,里边也会调用 helper method, 3.1 之前 assets 都是纯静态内容 具体你看https://github.com/wavii/rails-dev-tweaks

其实 3.0 也这样

打开 cache_classes 会不会导致后续代码修改没有被加载进去?

#10 楼 @huacnlee 我似乎不明显...大约一个表会增加 10-50ms 难道因为 ssd? 我看到有很多 system.namespaces 查找,是不是这个关系

另外,好像有时候,机器上库多了以后就会慢,貌似 3.1.2 的 bug 也是因为这个原因

#11 楼 @dotnil 开了 cache_classes 以后除非重启,不然代码的修改不会重新载入的

不用这么纠结吧,不就是响应增量的变化么?检测机制有么?inotify. 通知机制有么?内部捕获或者外部消息。加载机制有么?load. 简单方式我上面也说了,rails 里面跑个 EM 也不是什么难事

我用 webrick 会很慢,一般 dev 下 我都是用的 mongrel

求高手 解释 cache_classes 机制,研究过几天,没整出什么成果。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号