xmemcached 0.60 优化过程


   充分利用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甚至超过。



你可能感兴趣的:(多线程,算法,memcached,Google,网络协议)