zookeeper性能测试报告

Zookeeper性能测试报告
（version 1.0 2011-12-22）
suntaoyong@ 一、环境如下：
二、配置如下：
1.Zookeeper配置
tickTime = 2000
initLimit = 10
syncLimit = 5
maxClientCnxns = 0
log4j.rootLogger=TRACE, NOTICEFILE, WARNFILE
2.系统配置
/proc/sys/net/ipv4/tcp_max_syn_backlog 10240
/proc/sys/net/core/somaxconn 20480
文件句柄数limit –n 102400
JAVA_OPTS='-Xms1024m -Xmx10240m'
三、测试结果
目前的测试结果如下：
四、具体结果
说明：
1.1client = 1w请求，默认znode=100byte
2.测试工具基于社区smoke-test二次开发，在进行并发的时候，采用python多进程
3.测试机器一共5台机器，测试机与server会有3-3.8ms延迟，在进行单client连接的时候，如果没有网络延迟，参照1client无延迟结果。

4.为了排除网络延迟的影响，另外重新选一组机器进行测试，写请求极限仍然在同一个水平，这也证明了，在多并发的情况下，网络延迟是不会影响最终请求极限。

5．此次测试结果的写极限与社区和之前doris测试有一些差别，doris同步写极限能达到7656.06，而此次最高写（create）极限只有4800多，而这个数据十分稳定真实的，在多台机器实验证明过，很难突破5000。

而读极限要比doris高，说明并不是zk服务器性能比之
前差的问题。

6.zk异步性能要比同步性能高的多，这个结论是刚好与之前doris相反的，而这个结果是跟社区相符的。

7.在进行高并发的时候，zk的写性能并不高，很容易达到极限，原因有以下几点：1)zookeeper 的session是直接继承thread，意味着有多少sesson,就有线程在执行，而jvm在超过1024个线程就会出现调度很慢。

2)zookeeper的请求处理是一个请求流的形式，为了保证全局有序，每一个请求最终的处理都是串行处理的，所以再多的并发也没用，而且很容易达到极限，超过这个极限性能会下降。

8.下面的每一组分析结果都是基于真实数据反复测试统计分析所得！。