庄周梦蝶

生活、程序、未来
   :: 首页 ::  ::  :: 聚合  :: 管理

xmemcached 0.60 优化过程

Posted on 2009-03-06 14:37 dennis 阅读(1487) 评论(2)  编辑  收藏 所属分类: java涂鸦

   充分利用jprofile等工具观察性能瓶颈,才能对症下药,盲目的优化只是在浪费时间,并且效果可能恰恰相反
1、 观察到CountDownLatch.await占据最多CPU时间,一开始认为是由于jprofiler带来的影响,导致这个方法调用时间过长,从而忽 略了这一点,导致后面走了不少弯路。实际上await方法占用50%的CPU,而网络层和序列化开销却比较低,这恰恰说明这两者的效率低下,没办法充分利 用CPU时间,后来观察spymemcached的CPU占用情况,await占用的时间低于30%,优化后的结果也是如此。

2、因为没有深入理解这一点,我就盲目地开始优化,先从优化协议匹配算法开始,匹配ByteBuffer一开始用简单匹配(O(m*n)复杂 度),后来替代以KMP算法做匹配,想当然以为会更快,比较了两者效率之后才发现KMP的实现竟然比简单匹配慢了很多,马上google,得知比之kmp 算法效率高上几倍的有BM算法,马上实现之,果然比KMP和简单匹配都快。换了算法后,一测试,有提升,但很少,显然这不是热点。然后开始尝试改线程模型并测试,一开始想的是往上加线程,毕竟序列化是计算密集型,搞cpu个数的线程去发送command,调整读Buffer的线程数,测试效率没有提升甚至 有所降低,期间还测试了将协议处理改成批处理模式等,全部以失败告终。

3、此时才想起应该观察下spymemcached的CPU使用情况,才有了上面1点提到的观察,记的在测试yanf4j的echo server的时候,我发现读Buffer线程数设为0的事情下比之1的效率更高,也就是说仅启动一个线程处理Select、OP_WRITE和 OP_READ的事件,对于echo这样简单的任务来说是非常高效的,难道memcached也如此?立马设置为0并测试,果然提升很多,与 spymemcached的TPS差距一下减小了2000多,进一步观察,由于xmemcached构建在yanf4j的基础上,为了分层清晰导致在发送 和接收消息环节有很多冗余的操作,并且我还多启动了一个线程做command发送和优化get、set操作,如果能磨平这些差异,扩展yanf4j,避免了队列同步开销,这样也不用额外启动线程,效率是否更高呢?得益于yanf4j的模块化,修改工作顺利进行,最后的测试结果也证明了我的猜测,效率已经接近 spymemcached甚至超过。





评论

# re: xmemcached 0.60 优化过程  回复  更多评论   

2009-03-06 17:09 by Joshua Zhu
两个疑问:
1)KMP作为复杂度为O(m + n)的算法,会什么为慢“很多”?它是有可能比暴力法慢(这取决于串和模式的内容),但不可能慢很多吧。是不是你在Preprocessing time上花费了额外的时间呢?
2)BM算法确实在很多情况下都要比KMP高效一些,但是没有“高上几倍”这么夸张啵?

望庄老大不理赐教 :D

# re: xmemcached 0.60 优化过程  回复  更多评论   

2009-03-09 08:55 by dennis
尽管跟老朱讨论过了,还是回复下
1)KMP算法能那么快主要还是看模式的结构,如果重复模式多,那么跳跃的字符会更多,在xmemcached中的模式只是\r\n两个字节,因此KMP带来的益处基本没有,还不如简单匹配
2)“高上几倍”,完全是google出来的说辞,见谅:),算法我不懂

只有注册用户登录后才能发表评论。


网站导航: