Rails rails middleware 太多是否会有性能问题?

linjunhalida · 2013年04月11日 · 最后由 linjunhalida 回复于 2013年04月14日 · 5382 次阅读

刚才看了一下生产环境的 middleware,发现有一堆:

Rack::Cache Rack::Lock #ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x000000030c4f88 Rack::Runtime Rack::MethodOverride ActionDispatch::RequestId Rails::Rack::Logger ActionDispatch::ShowExceptions ActionDispatch::DebugExceptions ActionDispatch::RemoteIp Rack::Sendfile ActionDispatch::Callbacks ActiveRecord::ConnectionAdapters::ConnectionManagement ActiveRecord::QueryCache ActionDispatch::Cookies ActionDispatch::Session::CookieStore ActionDispatch::Flash ActionDispatch::ParamsParser Remotipart::Middleware ActionDispatch::Head Rack::ConditionalGet Rack::ETag ActionDispatch::BestStandardsSupport Warden::Manager ClientSideValidations::Middleware::Validators ExceptionNotifier Noie Barista::Server::Proxy NewRelic::Rack::BrowserMonitoring OmniAuth::Strategies::GoogleApps Rack::Pjax Sass::Plugin::Rack

然后一个个看下来没有什么可以去掉的,这么多 middleware 会不会有性能问题? 原理上面来说是每一个请求都有几十个方法嵌套, 不知道多那么多因此带来多少的性能损失,个人预估不会很大,大家谁测试过的,以及看法如何?我的看法是普通应用不要管那么多。。

那么,你遇到性能问题了吗?

#1 楼 @Rei 当然没有,只是想知道这里有多少潜力可挖。

你可以尝试一点一点的去掉,查看请求响应时间的差别,我之前试过去掉 Rails 默认那些,能少 20ms 左右,但是他们都不能去掉,都是有用处的。

#2 楼 @linjunhalida 这个 GuruDigger 那个应用的情况?你现在一般页面的响应时间是多少 ms?

我的经验是这两个起码没啥作用,你可以去掉 Rack::Runtime ActionDispatch::BestStandardsSupport

#5 楼 @edokeh 但是这两个去掉了,速度没啥变化

#6 楼 @huacnlee 说的也是。。。求个心理安慰吧。。。

很久以前的一篇文章: http://quake.iteye.com/blog/1473073 看你的项目具体情况,这些中间件是可以考虑去掉的:

Rack::Cache                 整页缓存
Rack::Runtime               记录X-Runtime(方便客户端查看执行时间)
ActionDispatch::RequestId       记录X-Request-Id(方便客户端查看请求具体在集群中的哪台执行)
ActionDispatch::RemoteIp        防止IP伪造(可以在web server上做)
ActionDispatch::Callbacks       设置callback
Rack::ConditionalGet            设置If-None-Match and If-Modified-Since
Rack::ETag              设置ETag
ActionDispatch::BestStandardsSupport    设置X-UA-Compatiblecd(可以在web server上做)

除非你的应用 GC 压力很大,一般无必要调整,特别是 Ruby 1.9.3 打过 GC patch 和 Ruby 2.0,直接用默认的吧。

#8 楼 @quakewang 你果然出现了,哈哈 一年前你也是这么回复我的 http://ruby-china.org/topics/2649

#9 楼 @edokeh 囧,你竟然还找得到那个帖子...

#10 楼 @quakewang 我发的嘛,当然一下就能找到了,而且我很少发帖,第一页就有

当然了,一个 rack middleware 即使什么都不做,也要创建对象,再加上 ruby 坑爹的 GC,不用的都应该去掉。

还是做加法好啊。

#13 楼 @zgm 用过一段时间 Archlinux 之后我就不喜欢做加法了。

#14 楼 @Rei 用了 Archlinux 之后我就更喜欢做加法了。

#8 楼 @quakewang 恩,这个资料留作备用,一般的状况不需要去动了~ #3 楼 @huacnlee 是大部分都需要(用的东西真是太复杂了啊),能够去掉的都不消耗什么资源。。20ms 级别的优化需要做的话估计就不用 rails 了~ #4 楼 @huacnlee 就是现在的网站,主要的大头还是各种 assets 的下载时间以及美国服务器的响应时间啊。。

#12 楼 @nouse 不理解 一个 Middleware 类及其实例才能占多少资源啊(而且似乎本来就是不回收的,Middleware 实例和整个服务器生命期基本一致)如果这点资源都怕占 还是用 C 改写吧。。。

如果负载比较低,没有多大差别的。如果用来做 API Server,请求负载很高的话,会有比较大性能差别。看我这篇Ruby 社区应该去 Rails 化了 去掉 10 个是 OK 的。

#18 楼 @robbin 你的文章似乎没有关于去除 middleware 前后性能测试的对比嘛 我自己拿 ab 测试了一下之后发现区别不是很大嘛。

我的经验也是去掉几个无关紧要的 middleware 后,没有性能上明显的提升。而且为了满足一些需求,我还需要添加几个 middleware。现在我我最大的希望于 Ruby 和 Rails 将来能努力消减掉多重 middleware 带来的性能损耗。

我的想法,没遇到性能问题,就没必要花时间处理。只要做到心里有个谱,以后如果碰到了性能问题,可以从哪些角度尝试优化就行。

性能调优是个花时间,容易让人沉迷,并且实际效果往往不那么有效的工作。性能调优讲究证据,但也因此容易让人产生“优化真的有很大效果”的错觉,慢慢改代码,重复跑测试,看着 server 响应时间一点点变短,确实有种成就感。但那些数据反映出来的优化效果也许在实际使用中就是一点点微不足道的感觉提升,当事人却为此花了大量时间,放弃了做更有意义事情的机会,关键是还乐在其中……

今天发现 ActionDispatch::Callbacks 这个 Middleware 好水,根本没什么意义,它能做的事情 middleware 也能干嘛。。难不成就是为了给别人写 insert_after,insert_before 时的参照物嘛?

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