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
0- 0
已为社区贡献4条内容
所有评论(0)