ZooKeeper的一个性能测试

xiaoxiao2024-03-21 130

3台ZooKeeper服务器。8核64位 jdk1.6；log和snapshot放在不同磁盘

场景一

同一个目录下，先create EPHEMERAL node，再delete；create和delete各计一次更新。没有订阅。一个进程开多个连接，每个连接绑定一个线程，在多个path下做上述操作；不同的连接操作的path不同

测试结果数据汇总如下：

dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal409620371585102476772802551472382说明总请求数实时TPS实时响应时间(ms)

场景二

一个进程开多个连接，每连接一个线程，每个连接在多个path下做下述操作；不同的连接操作的path不同每个path有3个订阅者连接，一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERAL node，不删除；创建前记录时间，订阅者收到event后记录时间(eventStat)；重新get到数据后再记录时间(dataStat)。共1000个pub连接，3000个sub连接，20W条数据。

结果汇总：getAfterNotify=false（只收事件，受到通知后不去读取数据）；五台4核client机器dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal40968000+520左右20481W+270左右10241W+256左右2551W+256左右说明总请求数实时TPS实时响应时间(ms) 收到通知后再去读取数据，五台4核client机器 dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotaleventStat40968000+1000左右eventStat409632002200-2600dataStat409632004000-4300eventStat10249500400-900dataStat10249500700-1100eventStat2568500200-1000dataStat2568500300-1400说明总请求数实时TPS实时响应时间(ms) 收到通知后再去读取数据，1台8核client机器 dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotaleventStat409657719604eventStat4096555810633dataStat4096555810743eventStat102460009400dataStat1024600010000eventStat256637410050dataStat256637410138说明总请求数实时TPS实时响应时间(ms)

场景三

一个进程开多个连接，每连接一个线程，每个连接在多个path下做下述操作；不同的连接操作的path不同每个path有一个修改者连接，没有订阅者。每个修改者在自己的每个path下设置数据。

结果汇总：getAfterNotify=false（只收事件，受到通知后不去读取数据）；五台4核client机器

dataSize(字节)

totalReq

recentTPS

avgTPS

recentRspTim

avgRspTim

failTotal

4096

2037

1585

1024

7677

280

255

14723

说明

总请求数

实时TPS

实时响应时间(ms)

总结由于一致性协议带来的额外网络交互，消息开销，以及本地log的IO开销，再加上ZK本身每1000条批量处理1次的优化策略，写入的平均响应时间总会在50-60ms之上。但是整体的TPS还是可观的。单个写入数据的体积越大，响应时间越长，TPS越低，这也是普遍规律了。压测过程中log文件对磁盘的消耗很大。实际运行中应该使用自动脚本定时删除历史log和snapshot文件。

本文来源于"阿里中间件团队播客",原文发表时间" 2011-07-15"