apache kafka系列之性能测试报告(虚拟机版)
测试方法在其他虚拟机上使用 Kafka 自带 kafka-producer-perf-test.sh 脚本进行测试 Kafka 写入性能尝试使用 kafka-simple-consumer-perf-test.sh 脚本测试 Kafka Consumer 性能,但由于获取到的数据不靠谱,放弃这个测试方法性能数据注:Gzip 和 Snappy 的传输速度 MB/S 是通过压缩前数据计
测试方法
在其他虚拟机上使用 Kafka 自带 kafka-producer-perf-test.sh 脚本进行测试 Kafka 写入性能
尝试使用 kafka-simple-consumer-perf-test.sh 脚本测试 Kafka Consumer 性能,但由于获取到的数据不靠谱,放弃这个测试方法
性能数据
注:Gzip 和 Snappy 的传输速度 MB/S 是通过压缩前数据计算的,压缩后的实际传输量并没有超过百兆网卡上限
单条消息大小 | batch size/条 | 线程数 | 压缩方式 | 传输速度 MB/S | 传输速度 Message/S |
0~1000 (avg 500) | 200 | 10 | 不压缩 | 11.1513 (约为百兆网卡上线) | 23369.8916 |
0~1000 (avg 500) | 200 | 10 | Gzip | 14.0450 | 29425.1878 |
0~1000 (avg 500) | 200 | 10 | Snappy | 32.2064 | 67471.7850 |
0~100(avg 50) | 200 | 10 | 不压缩 | 5.3654 | 111399.5121 |
0~100(avg 50) | 200 | 10 | Gzip | 2.6479 | 54979.4926 |
0~100(avg 50) | 200 | 10 | Snappy | 4.4217 | 91836.6410 |
0~1800 (avg 900) 仿线上数据量大小 | 200 | 10 | 不压缩 | 11.0518 (约为百兆网卡上线) | 12867.3632 |
0~1800 (avg 900) 仿线上数据量大小 | 200 | 10 | Gzip | 17.3944 | 20261.3717 |
0~1800 (avg 900) 仿线上数据量大小 | 200 | 10 | Snappy | 31.0658 | 36174.2150 |
以下数据为第二天测试数据 |
|
|
|
|
|
0~100(avg 50) | 200 | 10 | 不压缩 | 1.8482 | 38387.7159 |
0~100(avg 50) | 200 | 10 | Gzip | 1.3591 | 28219.0930 |
0~100(avg 50) | 200 | 10 | Snappy | 2.0213 | 41979.7658 |
0~100(avg 50) | 200 | 50 | 不压缩 | 2.0900 | 43402.7778 |
0~100(avg 50) | 200 | 50 | Gzip | 1.4639 | 30387.7477 |
0~100(avg 50) | 200 | 50 | Snappy | 2.0871 | 43323.8021 |
0~1000 (avg 500) | 200 | 10 | 不压缩 | 9.8287 | 20594.3530 |
0~1000 (avg 500) | 200 | 10 | Gzip | 13.0659 | 27386.0058 |
0~1000 (avg 500) | 200 | 10 | Snappy | 20.1827 | 42265.4269 |
0~1000 (avg 500) | 200 | 1 | 不压缩 | 7.0980 | 14885.6041 |
0~1000 (avg 500) | 200 | 1 | Gzip | 7.4438 | 15587.7356 |
0~1000 (avg 500) | 200 | 1 | Snappy | 15.3256 | 32088.3070 |
测试结论
1、线上的实际message平均大小略小于1k,在这种情况下(对应 0~1800 的test case),虚拟机可以应对每秒上万条写入请求。测试环境下,网络带宽是其瓶颈。通过压缩可以绕过瓶颈,Snappy算法可以处理36000+条请求每秒
2、在使用小数据进行测试时,Kafka每秒可以处理10万条左右数据,网络和IO都不是瓶颈,说明Kafka在虚拟机上处理写入请求的上限约为10万条每秒。
3、第二天的测试在相同条件下与第一天差距很大(0~100 大小数据,10线程,batch size 200),第二天在不压缩情况下只有第一天的三分之一的处理能力,snappy压缩情况下也只有二分之一处理能力,说明虚拟机的性能不够稳定。
4、生产者线程数对比,说明在网络和IO及Kafka处理能力没有达到瓶颈时,更多的线程能够增加写入速度,但是增长不明显。
测试推论
1、虚拟机上的Kafka最高也可以处理10万条请求,物理机的处理能力强得多,应当超过10万条每秒的处理能力。对应线上平均数据大小接近1K,处理数据流量能力不会低于100MB/S,接近千兆网卡上限。说明物理机上,在遇到网络带宽瓶颈前,Kafka性能应当不会是瓶颈。
2、虚拟机测试是在单topic 单replication 的情况下测试的。无法确定在多个replication时性能下降情况。从网上查找看,性能下降不是很明显。
3、从测试看,虚拟机的性能能够承担线上请求。但虚拟机性能不稳定,需要非常谨慎。
更多推荐
所有评论(0)