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