请注意Rails2.3自带的memcache-client有性能问题

Rails2.3版本发布了，这个版本内部的改动非常大，相关介绍可以看JavaEye这篇新闻：http://www.iteye.com/news/5390，估计最近也有不少人开始动手升级到Rails2.3了，JavaEye也不例外，这一升级才发现性能低得令人发指。

由于过于信任Rails框架，没有进行本地性能测试，在通过了兼容性测试就兴冲冲上线了。这一上线，动态请求立刻堵了一大堆，仔细看了看fastcgi的crash log，发现大量请求在flush数据的时候发生broen pipe。打开Rails2.3新采用的Rack框架源代码当中fastcgi的adapter一看，这代码写的太不负责了！fastcgi协议本身是没有设定缓冲区的，写出去的数据立刻就发送掉了，结果Rack还非常多余的在每次写数据之后flush一下，造成了连接已经关闭之后，fastcgi还傻傻的等着flush数据呢！

自行修改了Rack的fastcgi adapter，本地运行压力测试，fastcgi不再报错，代码上线发布，立刻又堵住了，load非常高，这下开始怀疑是不是Rack的fastcgi支持的不好，导致的性能差？ 由于thin是对Rack支持最好的Rails应用服务器，因此我们把网站rails运行方式从fastcgi改成了thin，再次代码上线发布，又堵住了，而且堵的更严重，load比刚才用fastcgi还要高很多！ 由此也可以看出来，fastcgi毕竟还是Rails性能最好的运行方式。

完全排除了fastcgi的问题，又排查了好几处可能造成性能影响的地方，还是无法解决rails2.3一上线请求就被堵塞的问题。最后老老实实在本地进行了性能测试，这下终于真相大白。在我本地MacOSX的环境下面，rails2.2的情况下每秒可以处理40个请求，但是rails2.3每秒只能处理25个请求，同时CPU消耗的更多，进程内存占用更高！

最后真正的原因是Rails2.3自带的memcache-client有重大性能问题

简单的来说，Rails2.2自带的memcache-client是1.5.0版本，这是一个用了很久很稳定的版本了，也是目前 memcache-client官方正式发布版本；而Rails2.3的memcache-client升级到了1.6.5版本，这是一个全新的版本，仅仅在github上面，并未正式发布，可以看成一个开发当中的版本，而这个版本有无数的问题！

第一、它设置了一个怪异的timeout参数，默认情况下，导致连接memcache server的速度变得异常缓慢，把该timeout参数改成nil以后，速度恢复正常

第二、它把连接memcache server的每个方法操作改成了闭包调用，固然代码和异常处理显得优雅一些，但是性能测试表明，整体应用性能会下降很多。

第三、它里面的代码还有一些自相矛盾的地方，比方说多线程的检测和处理代码有错误

总之，在把rails2.3的memcache client版本换成老的1.5.0版本以后，性能问题得到了解决，而且在本地性能测试的结果表明，在rails2.3上面运行JavaEye代码，速度比rails2.2上面还要提升了11%的性能，但是内存消耗有所上升（估计是rails2.3的local cache带来的）。

当然memcache-client 1.6.5也不是一无是处，他添加了自动故障转移的能力（在多个memcached server之间），内部代码也进行了一些重构(尽管重构的结果是性能更低下)，添加了一些多线程支持（尽管这部分代码根本不能正常工作），不过毕竟这还是一个开发当中不成熟的版本，rails不应该很草率的就升级了memcache client版本。

评论

96 楼 wimap 2009-08-25  

哎 我们新进来的就麻烦了 跟新的吧 没中文书 E文又不好 只好回到 1.86 下 没选择 弄熟了再说

95 楼 carlosbdw 2009-05-06  

现在在用mod_rails，感觉方便多了，不是每个应用都那么重的。

94 楼 J2EE&forever 2009-04-24  

J2EE&forever 写道

J2EE&forever 写道
不错。很强大 请求巍峨巍峨

3222

93 楼 J2EE&forever 2009-04-24  

J2EE&forever 写道

不错。很强大

请求巍峨巍峨

92 楼 J2EE&forever 2009-04-24  

不错。很强大

91 楼 conect 2009-04-16  

问robbin一个memcache的问题

一个数据量庞大的留言列表,默认只显示三个月内的留言,还有 一个星期内的留言,一个月内的留言,三个月内的留言,三个月到一年的留言,一年到二年的留言 (两年以后的留言删除),这样的时间段缓存如何实现?

我使用的是memcached,IBatis,Spring,MySQL,我目前的方案是选择一个星期的时候,封装一个星期做参数到一个map中(还包括其他参数),同样一个月做参数封装到一个map中,三个月的map,这三个map通过IBatis拿值并做精确缓存,在做添加,修改等操作时实时更新缓存,制约三个月到一年,一年到二年可以非精确缓存 ,这样的方案有没问题,不知道你有更好的方法吗?

90 楼 QuakeWang 2009-04-15  

genki 写道

看到社区有人在讨论这个问题了。http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/fb60e23a7d345a81?hl=en

我测试过2.3带的那个版本memcache-client，设置timeout为nil和2.2相比还是有不小的性能差距（robbin在文章中也提到了）
从讨论中看，也提到了基于c的libmemcached，我测试下来这个库的性能是最好的（基于单台cache server），可是解决了这个client问题最终以后还是从2.3回退了，我们的应用64位操作系统上用2.3跑，平均每个进程要240M，而2.2只要190M，开20个进程就要多1G内存，服务器资源有点紧张。

不过换了client以后，从单个进程能够处理的请求数目来看2.3比2.2又有少许提高(5%左右)，如果你的服务器资源不是限制的话，可以考虑升级到2.3。

89 楼 genki 2009-04-15  

the new memcache-client is slower than 1.5.0!?

Yes, in the simplest case, 1.6.x+ is slower than 1.5.0. If you just have a single memcached server, the latest memcache-client will be significantly slower. This is because 1.5.0 does not timeout network operations. For reliability purposes, memcache-client 1.6.x+ enables timeouts by default.

Unfortunately Ruby’s network timeout options are not very performant. If you want timeouts, the best you can do currently is install the SystemTimer gem, which will approximately halve the overhead incurred by timeouts. If you need ultimate speed, you can disable timeouts or use Fauna’s memcached library which moves most of the client into native C. (Hint: if you are looking for a fun tuning project and are good with C, the SystemTimer gem has a lot of room for improvement in performance.)

If you are using multiple memcached servers, 1.6.x+ will be much faster than 1.5.0 as 1.5.0 had an extremely slow hashing function to map a key to a server. Overall, production environments with multiple servers should see performance and reliability improvements in memcache-client 1.6.x+.

88 楼 genki 2009-04-15  

看到社区有人在讨论这个问题了。http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/fb60e23a7d345a81?hl=en


有人给出了个答案，不知道是不是这样：

I've added a FAQ entry explaining what is going on.  1.6+ is much
faster than 1.5.0 only when multiple servers are being used.  I'm
guessing your benchmark is testing just localhost:11211.

http://github.com/mperham/memcache-client/blob/d5ae15d362c379c3a6692e...

Simple answer, turn off socket timeouts in order to dramatically speed
up memcache-client but realize you might be woken up at 3am when
production melts down, as I was.

mike

87 楼 seemoon 2009-03-30  

想到那个美国系列剧“成长的烦恼”，剧情很有趣也很精彩。
ｒａｉｌｓ是一个革新的ｆｒａｍｅ，应该多点耐心，多上点心。
ｒａｉｌｓ是最贴近ａｇｉｌｅ的框架之一，很值得投入和期待。

86 楼 wosmvp 2009-03-30  

memcache-client  1.7.1 发布
* Performance optimizations:
  * Rely on higher performance operating system socket timeouts for low-level socket
    read/writes where possible, instead of the (slower) SystemTimer or (slowest,
    unreliable) Timeout libraries.
  * the native binary search is back!  The recent performance tuning made the binary search
    a bottleneck again so it had to return.  It uses RubyInline to compile the native extension and
    silently falls back to pure Ruby if anything fails.  Make sure you run:
    `gem install RubyInline` if you want ultimate performance.
  * the changes make memcache-client 100% faster than 1.7.0 in my performance test on Ruby 1.8.6:
    15 sec -> 8 sec.
* Fix several logging issues.

85 楼 rubynroll 2009-03-30  

其实很多开源项目都有类似的版本升级太快，旧版本维护不力的问题。

因此应用一个开源产品（特别是那种由社区推动的开源产品）的时候，很重要的一点就是参与到这个社区，理解这个社区的文化。

很多年前，因为一个项目的需要第一次开始写Linux内核驱动，那个时候天天在骂娘，怎么内核API老在变，怎么就不能考虑向下兼容呢？....当后来逐渐理解内核开发社区的文化之后就再也没有抱怨了。

我相信rails社区肯定也存在某种特定的文化驱动当前rails的发展模式。既然要用它，就应该顺应它的文化。

84 楼 richyzhang 2009-03-29  

ychael 写道

robbin 写道

murainwood 写道

Rails是个好东西，开发团队不行，如果能被大公司收购，会不会能好些？

rails core team的能力没的说，创新能力非常出众，每次新版本都会有令用户意想不到但是非常有用的创新功能推出，而且能够连续多年，持续高产的创新，这本身就是惊人的成就。rails在web框架领域的创新能力，总是让我想起苹果在消费电子领域的创新能力。可以这样说，在web开发框架领域，rails把其它所有竞争对手，包括python的那些知名框架，甩开了不知有多少条街的差距，是无可争议的王者。任何想要选择web快速开发框架，重视生产力的开发者，rails都是唯一的选择。

当然rails并不完美，不过对我来说都还可以接受，真正让人受不了的是core team对新版本升级无比的热衷，但是对老版本的维护却不闻不问。这样的话对于一些强调稳定性、兼容性和高负载的web应用，就必须自己亲自解决一些rails框架升级速度过快带来的维护方面的缺失。

要解决这个问题在于core team自己的态度，是不是可以拿出更多的精力放在老版本维护上面，放慢一些版本创新和升级的速度呢？我觉得以现在的rails的功能性来说，已经超越其它web框架若干年的水准了，没必要再玩命的创新和升级了，这样做固然把竞争对手甩的越来越遥远，但是也把自己的用户玩死了，多花点精力维护老版本，对rails本身的应用普及更有好处。

我有点想说，玩死你们

真正玩死人的是不能把事干掉的东西.

83 楼 ychael 2009-03-29  

robbin 写道

murainwood 写道

Rails是个好东西，开发团队不行，如果能被大公司收购，会不会能好些？

rails core team的能力没的说，创新能力非常出众，每次新版本都会有令用户意想不到但是非常有用的创新功能推出，而且能够连续多年，持续高产的创新，这本身就是惊人的成就。rails在web框架领域的创新能力，总是让我想起苹果在消费电子领域的创新能力。可以这样说，在web开发框架领域，rails把其它所有竞争对手，包括python的那些知名框架，甩开了不知有多少条街的差距，是无可争议的王者。任何想要选择web快速开发框架，重视生产力的开发者，rails都是唯一的选择。

当然rails并不完美，不过对我来说都还可以接受，真正让人受不了的是core team对新版本升级无比的热衷，但是对老版本的维护却不闻不问。这样的话对于一些强调稳定性、兼容性和高负载的web应用，就必须自己亲自解决一些rails框架升级速度过快带来的维护方面的缺失。

要解决这个问题在于core team自己的态度，是不是可以拿出更多的精力放在老版本维护上面，放慢一些版本创新和升级的速度呢？我觉得以现在的rails的功能性来说，已经超越其它web框架若干年的水准了，没必要再玩命的创新和升级了，这样做固然把竞争对手甩的越来越遥远，但是也把自己的用户玩死了，多花点精力维护老版本，对rails本身的应用普及更有好处。

我有点想说，玩死你们

82 楼 rollingwoods 2009-03-28  

RoR技术上是不错的，但是，这种版本管理方式，只能给RoR使用者带来应用风险。
随随便便的release是不应该的。。。
还是年轻气盛啊。。。

81 楼 richyzhang 2009-03-27  

robbin 写道

建议不要升级到Rails2.3版本！

Rails core team已经把全部精力都放到了Rails3.0的开发中去了，而3.0的预期发布日期是在5月4日！ 是的，你没有看错！在Rails2.3刚刚发布不到两个月的时间，Rails3.0马上就要出来了。2.3是一个试验性质的版本，它包含了很多Rails3.0要发布功能的向下移植，所以内部代码做了很多结构性修改。现在由于3.0的发布在即，core team已经没有精力理会刚刚发布出来的2.3了，2.x的issue track上面积累了388个issue没有fix。

2.3更象是给在2.2发布之后到圣诞节前这段时间的工作做一个交代,Rails3才是真正的第二代rails.看看Yehuda能给rails core带来些什么,值得期待.

80 楼 robbin 2009-03-27  

建议不要升级到Rails2.3版本！

Rails core team已经把全部精力都放到了Rails3.0的开发中去了，而3.0的预期发布日期是在5月4日！ 是的，你没有看错！在Rails2.3刚刚发布不到两个月的时间，Rails3.0马上就要出来了。2.3是一个试验性质的版本，它包含了很多Rails3.0要发布功能的向下移植，所以内部代码做了很多结构性修改。现在由于3.0的发布在即，core team已经没有精力理会刚刚发布出来的2.3了，2.x的issue track上面积累了388个issue没有fix。

79 楼 fanix 2009-03-26  

javaeye团队的效率非常高！

其实2.3.2已经进步不少了，可以看出rails开发团队也在不断成熟，这次升级都没有报错就是个证明。

期待rails真正长大的那一天，让我们所有rails粉可以舒舒服服安安心心快快乐乐的使用。

78 楼 Anxonli 2009-03-26  

Robbin的发现，证明了Rails 2.3，并不是之前说的那么的差，我在development环境下开发，没有用memcached，就感觉Rails 2.3的性能没有那么的差劲。我也非常同意Robbin的说法，Rails的升级太快了，从未见过一个框架每几个月升级一个版本。以前觉得，Visual Studio 2005刚用熟，Visual 2008又来了。现在才明白，Rails更快n倍。

Robbin觉得Racks 和 Metal又是高级玩具，还是非常实用的东西呢？

77 楼 richyzhang 2009-03-25  

不错,总算不用再去想2.3性能比起2.2怎么差那么多,总算可以继续放心地使用嵌套form.
多一个部件,就多一份出错的可能啊.