欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

xmemcached 0.60 优化过程

程序员文章站 2022-03-01 14:33:44
...


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