请注意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版本。

其实对高性能需求的网站，是不是应该在功能定型后逐渐从 rails 里面转移出来呢？快速开发的灵活性和面对大负载的性能应该是一个矛盾。

问题是JavaEye的功能还远远没有定型，网站还在快速进化过程中。

Rails 2.3 我更感觉像一个过渡版本，能不更新就不更新呗……

期待Merb在Rails里发挥更大作用

老实说我真的不指望。看看那帮人，包括DHH整天吹捧mod_rails我就知道指望不上。mod_rails这种玩意，我就说一句话，高负载的Rails网站用mod_rails是不负责任的。

以JavaEye目前的大流量和低端硬件，只有lighttpd/fcgi能稳定的支撑下来，其它的什么thin/mongrel/mod_rails只要一上，统统堵住。他们这些人如果没有像我们这样的切肤之痛，是不可能重视这个问题的。

刚搭建好平台准备上2.3.2的，看这样我还是乖乖的回到1.8.7下面来部署2.0.2。

robbin 大哥，你应该写信去批评下他们。给他们指导指导，毕竟你是实践了的，有发言权。

顺便再告诉你一件令人发指的事情：在ruby1.9.1上面跑rails2.3.2，其性能比ruby1.8.7跑rails2.3.2还要差。

至于那个吹到天上去的REE性能也很一般，经过我们JavaEye网站的实际运营比较下来看，目前性能和稳定性最好的就是用lighttpd/fcgi，ruby用1.8.7p72（打GC patch），rails用2.2.2。

顺便问一下，ruby用的是什么版本？1.9.1p吗？