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

文章转自庄周梦蝶  ，原文发布时间2009-03-06