apache kafka系列之性能测试报告(虚拟机版)

测试方法

在其他虚拟机上使用 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、从测试看，虚拟机的性能能够承担线上请求。但虚拟机性能不稳定，需要非常谨慎