Posted on 2009-03-06 14:37
dennis 閱讀(1498)
評論(2) 編輯 收藏 所屬分類:
java 、
涂鴉
充分利用jprofile等工具觀察性能瓶頸，才能對癥下藥，盲目的優(yōu)化只是在浪費時間，并且效果可能恰恰相反
1、
觀察到CountDownLatch.await占據(jù)最多CPU時間，一開始認為是由于jprofiler帶來的影響，導(dǎo)致這個方法調(diào)用時間過長，從而忽
略了這一點，導(dǎo)致后面走了不少彎路。實際上await方法占用50%的CPU，而網(wǎng)絡(luò)層和序列化開銷卻比較低，這恰恰說明這兩者的效率低下，沒辦法充分利
用CPU時間，后來觀察spymemcached的CPU占用情況，await占用的時間低于30％，優(yōu)化后的結(jié)果也是如此。
2、因為沒有深入理解這一點，我就盲目地開始優(yōu)化，先從優(yōu)化協(xié)議匹配算法開始，匹配ByteBuffer一開始用簡單匹配(O(m*n)復(fù)雜
度），后來替代以KMP算法做匹配，想當(dāng)然以為會更快，比較了兩者效率之后才發(fā)現(xiàn)KMP的實現(xiàn)竟然比簡單匹配慢了很多，馬上google，得知比之kmp
算法效率高上幾倍的有BM算法，馬上實現(xiàn)之，果然比KMP和簡單匹配都快。換了算法后，一測試，有提升，但很少，顯然這不是熱點。然后開始嘗試改線程模型并測試，一開始想的是往上加線程，畢竟序列化是計算密集型，搞cpu個數(shù)的線程去發(fā)送command，調(diào)整讀Buffer的線程數(shù)，測試效率沒有提升甚至
有所降低，期間還測試了將協(xié)議處理改成批處理模式等，全部以失敗告終。
3、此時才想起應(yīng)該觀察下spymemcached的CPU使用情況，才有了上面1點提到的觀察，記的在測試yanf4j的echo
server的時候，我發(fā)現(xiàn)讀Buffer線程數(shù)設(shè)為0的事情下比之1的效率更高，也就是說僅啟動一個線程處理Select、OP_WRITE和
OP_READ的事件，對于echo這樣簡單的任務(wù)來說是非常高效的，難道m(xù)emcached也如此？立馬設(shè)置為0并測試，果然提升很多，與
spymemcached的TPS差距一下減小了2000多，進一步觀察，由于xmemcached構(gòu)建在yanf4j的基礎(chǔ)上，為了分層清晰導(dǎo)致在發(fā)送
和接收消息環(huán)節(jié)有很多冗余的操作，并且我還多啟動了一個線程做command發(fā)送和優(yōu)化get、set操作，如果能磨平這些差異，擴展yanf4j，避免了隊列同步開銷，這樣也不用額外啟動線程，效率是否更高呢？得益于yanf4j的模塊化，修改工作順利進行，最后的測試結(jié)果也證明了我的猜測，效率已經(jīng)接近
spymemcached甚至超過。