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

发布时间:2014-10-25 2:20:39
来源:分享查询网

Rails2.3版本发布了,这个版本内部的改动非常大,相关介绍可以看JavaEye这篇新闻:http://www.javaeye.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版本。

返回顶部
查看电脑版