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