3台ZooKeeper服务器。8核64位jdk1.6；log和snapshot放在不同磁盘
场景一
同一个目录下，先createEPHEMERALnode，再delete；create和delete各计一次更新。没有订阅。
一个进程开多个连接，每个连接绑定一个线程，在多个path下做上述操作；不同的连接操作的path不同
测试结果数据汇总如下：
| dataSize(字节) | totalReq | recentTPS | avgTPS | recentRspTim | avgRspTim | failTotal | ||
| 4096 | 2037 | 1585 | ||||||
| 1024 | 7677 | 280 | ||||||
| 255 | 14723 | 82 | ||||||
| 说明 | 总请求数 | 实时TPS | 实时响应时间(ms) | |||||
场景二
一个进程开多个连接，每连接一个线程，每个连接在多个path下做下述操作；不同的连接操作的path不同
每个path有3个订阅者连接，一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERALnode，不删除；创建前记录时间，订阅者收到event后记录时间(eventStat)；重新get到数据后再记录时间(dataStat)。共1000个pub连接，3000个sub连接，20W条数据。
| 结果汇总：getAfterNotify=false（只收事件，受到通知后不去读取数据）；五台4核client机器 | |||||||
| dataSize(字节) | totalReq | recentTPS | avgTPS | recentRspTim | avgRspTim | failTotal | |
| 4096 | 8000+ | 520左右 | |||||
| 2048 | 1W+ | 270左右 | |||||
| 1024 | 1W+ | 256左右 | |||||
| 255 | 1W+ | 256左右 | |||||
| 说明 | 总请求数 | 实时TPS | 实时响应时间(ms) | ||||
收到通知后再去读取数据，五台4核client机器
| dataSize(字节) | totalReq | recentTPS | avgTPS | recentRspTim | avgRspTim | failTotal | |
| eventStat | 4096 | 8000+ | 1000左右 | ||||
| eventStat | 4096 | 3200 | 2200-2600 | ||||
| dataStat | 4096 | 3200 | 4000-4300 | ||||
| eventStat | 1024 | 9500 | 400-900 | ||||
| dataStat | 1024 | 9500 | 700-1100 | ||||
| eventStat | 256 | 8500 | 200-1000 | ||||
| dataStat | 256 | 8500 | 300-1400 | ||||
| 说明 | 总请求数 | 实时TPS | 实时响应时间(ms) |
收到通知后再去读取数据，1台8核client机器
| dataSize(字节) | totalReq | recentTPS | avgTPS | recentRspTim | avgRspTim | failTotal | |
| eventStat | 4096 | 5771 | 9604 | ||||
| eventStat | 4096 | 5558 | 10633 | ||||
| dataStat | 4096 | 5558 | 10743 | ||||
| eventStat | 1024 | 6000 | 9400 | ||||
| dataStat | 1024 | 6000 | 10000 | ||||
| eventStat | 256 | 6374 | 10050 | ||||
| dataStat | 256 | 6374 | 10138 | ||||
| 说明 | 总请求数 | 实时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 | 82 | ||||||
| 说明 | 总请求数 | 实时TPS | 实时响应时间(ms) | |||||
总结
由于一致性协议带来的额外网络交互，消息开销，以及本地log的IO开销，再加上ZK本身每1000条批量处理1次的优化策略，写入的平均响应时间总会在50-60ms之上。但是整体的TPS还是可观的。单个写入数据的体积越大，响应时间越长，TPS越低，这也是普遍规律了。压测过程中log文件对磁盘的消耗很大。实际运行中应该使用自动脚本定时删除历史log和snapshot文件。
©著作权归作者所有：来自51CTO博客作者阿里中间件的原创作品，如需转载，请注明出处，否则将追究法律责任