• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            loop_in_codes

            低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

            zookeeper節點數與watch的性能測試

            zookeeper中節點數量理論上僅受限于內存,但一個節點下的子節點數量受限于request/response 1M數據 (size of data / number of znodes)

            zookeeper的watch機制用于數據變更時zookeeper的主動通知。watch可以被附加到每一個節點上,那么如果一個應用有10W個節點,那zookeeper中就可能有10W個watch(甚至更多)。每一次在zookeeper完成改寫節點的操作時就會檢測是否有對應的watch,有的話則會通知到watch。Zookeeper-Watcher機制與異步調用原理

            本文將關注以下內容:

            • zookeeper的性能是否會受節點數量的影響
            • zookeeper的性能是否會受watch數量的影響

            測試方法

            在3臺機器上分別部署一個zookeeper,版本為3.4.3,機器配置:

            Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz
            
            16G
            
            java version "1.6.0_32"
            Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
            OpenJDK (Taobao) 64-Bit Server VM (build 20.0-b12-internal, mixed mode)
            

            大部分實驗JVM堆大小使用默認,也就是1/4 RAM

            java -XX:+PrintFlagsFinal -version | grep HeapSize
            

            測試客戶端使用zk-smoketest,針對watch的測試則是我自己寫的。基于zk-smoketest我寫了些腳本可以自動跑數據并提取結果,相關腳本可以在這里找到:https://github.com/kevinlynx/zk-benchmark

            測試結果

            節點數對讀寫性能的影響

            測試最大10W個節點,度量1秒內操作數(ops):

            可見節點數的增加并不會對zookeeper讀寫性能造成影響。

            節點數據大小對讀寫性能的影響

            這個網上其實已經有公認的結論。本身單個節點數據越大,對網絡方面的吞吐就會造成影響,所以其數據越大讀寫性能越低也在預料之中。

            寫數據會在zookeeper集群內進行同步,所以其速度整體會比讀數據更慢。該實驗需要把超時時間進行一定上調,同時我也把JVM最大堆大小調整到8G。

            測試結果很明顯,節點數據大小會嚴重影響zookeeper效率。

            watch對讀寫性能的影響

            zk-smoketest自帶的latency測試有個參數--watch_multiple用來指定watch的數量,但其實僅是指定客戶端的數量,在server端通過echo whcp | nc 127.0.0.1 4181會發現實際每個節點還是只有一個watch。

            在我寫的測試中,則是通過創建多個客戶端來模擬單個節點上的多個watch。這也更符合實際應用。同時對節點的寫也是在另一個獨立的客戶端中,這樣可以避免zookeeper client的實現對測試帶來的干擾。

            每一次完整的測試,首先是對每個節點添加節點數據的watch,然后在另一個客戶端中對這些節點進行數據改寫,收集這些改寫操作的耗時,以確定添加的watch對這些寫操作帶來了多大的影響。

            圖中,0 watch表示沒有對節點添加watch;1 watch表示有一個客戶端對每個節點進行了watch;3 watch表示有其他3個客戶端對每個節點進行了watch;依次類推。

            可見,watch對寫操作還是有較大影響的,畢竟需要進行網絡傳輸。同樣,這里也顯示出整個zookeeper的watch數量同節點數量一樣對整體性能沒有影響。

            總體結論

            • 對單個節點的操作并不會因為zookeeper中節點的總數而受到影響
            • 數據大小對zookeeper的性能有較大影響,性能和內存都會
            • 單個節點上獨立session的watch數對性能有一定影響

            posted on 2014-09-21 20:56 Kevin Lynx 閱讀(4944) 評論(0)  編輯 收藏 引用 所屬分類: network

            婷婷久久五月天| 国产成人久久久精品二区三区| 女人高潮久久久叫人喷水| 97精品伊人久久大香线蕉| 亚洲欧洲日产国码无码久久99| 国产精品久久久久久久久| 久久久久久A亚洲欧洲AV冫| 欧美日韩精品久久免费| 精品国产一区二区三区久久| 2020国产成人久久精品| 亚洲乱亚洲乱淫久久| 久久精品国产亚洲AV不卡| 久久免费高清视频| 狠狠色婷婷久久一区二区 | 2019久久久高清456| jizzjizz国产精品久久| 伊人精品久久久久7777| 久久99国产精品成人欧美| 久久久久成人精品无码中文字幕| 色偷偷88欧美精品久久久| 热久久这里只有精品| 嫩草伊人久久精品少妇AV| 亚洲欧美一区二区三区久久| 久久精品国产亚洲Aⅴ香蕉| .精品久久久麻豆国产精品| 国产精品久久久久久久人人看| 精品国产乱码久久久久久浪潮| 2020最新久久久视精品爱| 久久精品一本到99热免费| 精品人妻伦九区久久AAA片69| 久久综合亚洲色HEZYO国产| 91久久精品国产免费直播| 草草久久久无码国产专区| 久久精品国产91久久综合麻豆自制 | 人妻丰满AV无码久久不卡| 7777久久久国产精品消防器材| 久久久国产亚洲精品| 伊人久久大香线蕉综合热线| 中文字幕久久亚洲一区| 97久久国产综合精品女不卡| 亚洲成色www久久网站夜月|