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)