2011-07-15 18:07:00
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博客作者阿里中间件的原创作品,如需转载,请注明出处,否则将追究法律责任
http://blog.51cto.com/aliapp/1327653