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文件。