请注意Rails2.3自带的memcache-client有性能问题
程序员文章站
2022-03-09 12:25:07
...
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版本。
由于过于信任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版本。