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數對性能有必定影響