目录

ZooKeeper的一个性能测试

ZooKeeper的一个性能测试

2011-07-15 18:07:00

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

场景一

同一个目录下,先createEPHEMERALnode,再delete;create和delete各计一次更新。没有订阅。

一个进程开多个连接,每个连接绑定一个线程,在多个path下做上述操作;不同的连接操作的path不同

测试结果数据汇总如下:

dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal
409620371585
10247677280
2551472382
说明总请求数实时TPS实时响应时间(ms)

场景二

一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同

每个path有3个订阅者连接,一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERALnode,不删除;创建前记录时间,订阅者收到event后记录时间(eventStat);重新get到数据后再记录时间(dataStat)。共1000个pub连接,3000个sub连接,20W条数据。

结果汇总:getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal
40968000+520左右
20481W+270左右
10241W+256左右
2551W+256左右
说明总请求数实时TPS实时响应时间(ms)

收到通知后再去读取数据,五台4核client机器

dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal
eventStat40968000+1000左右
eventStat409632002200-2600
dataStat409632004000-4300
eventStat10249500400-900
dataStat10249500700-1100
eventStat2568500200-1000
dataStat2568500300-1400
说明总请求数实时TPS实时响应时间(ms)

收到通知后再去读取数据,1台8核client机器

dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal
eventStat409657719604
eventStat4096555810633
dataStat4096555810743
eventStat102460009400
dataStat1024600010000
eventStat256637410050
dataStat256637410138
说明总请求数实时TPS实时响应时间(ms)

场景三

一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同

每个path有一个修改者连接,没有订阅者。每个修改者在自己的每个path下设置数据。

结果汇总:getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
dataSize(字节)totalReqrecentTPSavgTPSrecentRspTimavgRspTimfailTotal
409620371585
10247677280
2551472382
说明总请求数实时TPS实时响应时间(ms)

总结

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

©著作权归作者所有:来自51CTO博客作者阿里中间件的原创作品,如需转载,请注明出处,否则将追究法律责任