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

我们已经找到原因了：是Rails2.3.2的memcache client有性能问题，如果从2.2.2升级上来的，你需要手工修改一下配置文件，加上timeout为nil:
config.cache_store = :mem_cache_store, "localhost", {:timeout => nil}

不过即便改了timeout，由于这个client加入了multithread和大量的block写法，比2.2.2的性能还要差15~30%，建议大家可以先用2.2.2 memcache client替换。

我们准备用不同的memcache client测试性能，然后给rails开发团队提交一个对比报告，希望下个版本可以改进。

呵呵，赞一个，厉害javaeye，这样那些不敢用的又敢用了

这个是实际应用的实话。就像当年比较中国和印度程序员的区别一样。内存硬盘大大的，谁还在乎
～

QuakeWang 和 robbin 很好很强大 没了性能的困扰+那么多有用的功能,大家都该升级了吧!  MS memcache-client 已经升级到了1.7.1 , 跟 1.5.0 相比 , 性能可是飕飕的呀 , 不知javaeye试过了没 ? http://github.com/mperham/memcache-client/blob/dc0734354fd5b55a8755a7933927f94a321bc7dd/performance.txt

看来作者自己也意识到了1.6.5的Timout有问题，所以1.7.1的版本去掉了Timeout部分的代码，改成了依赖system_timer这个gem，不过我测试下来的结果看，性能比1.6.5固然有很大提高，但是还是比1.5.0差很多，在关闭timeout的情况下，1.7.1和1.6.5性能是一样的，都比1.5.0差一些（因为使用了闭包调用）

尽管作者自己提供了性能测试的testcase和测试结果，但是我觉得他那个测试过于简单了，可能无法测试真实环境下对整体性能的影响，比方说在完整的rails环境中可能造成ruby进程GC行为的差异，而这一点在这个testcase这么简单的操作环境下不会被暴露出来。

现在看来还是libmemcached的性能最好，尽管安装ibmemcached的ruby client非常麻烦。

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

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

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

javaeye团队的效率非常高！

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

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

建议不要升级到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带来些什么,值得期待.