原文地址：http://www.louisvv.com/archives/2127.html
许久不见，最近工作有点忙，没来得及更博
这段时间对几个大数据框架做了BenchMark(基准测试)，待整理后，会分享出来
关于BenchMark
简单的来说，BenchMark是一个系统性能的测量工作，也可以看做是一种评价方式
主要测试负载的执行时间、传输速度、吞吐量、资源占用率等
对系统进行性能基准测试后，将得到的基准数据作为性能指标的参照物，可用于以下场景
1.任意一项变更为系统产生的影响
修改某项配置参数后（启用某项参数），系统的变化情况
2.系统环境的变更对系统性能产生的影响
3.在相同场景下，不同框架的系统性能表现的差异
一些大数据BenchMark工具：
1.Hibench：由Intel开发的针对Hadoop的基准测试工具
2.Berkeley BigDataBench：随着Spark的推出，由AMPLab开发的一套大数据基准测试工具
3.Hadoop GridMix：Hadoop自带的Benchmark，作为Hadoop自带的测试工具使用方便、负载经典，应用广泛
除此之外，有些大型的框架会自带BenchMark工具，方便进行测试
了解BenchMark后，就要开始今天的文章：Kafka基准测试
分别实用Kafka自带的基准工具对Kafka Producer/Consumer进行性能基准测试
Kafka版本：Scala_2.11-1.1.0
服务器配置：
三台服务器
- IntelXeon 3.2 GHz * 12 cores
- 251GB RAM
- Red Hat 7.5
- 10 Gb Ethernet
Kafka Producer基准测试
测试背景
需要对Kafka Producer在不同参数下的性能
性能指标
平均吞吐量（条/秒）、平均延时（毫秒）、平均吞吐率速率（MB/秒）
测试方法
使用Kafka基准测试工具kafka-producer-perf进行测试
这个工具位于kafka/bin目录下
这里仅简单介绍一下该工具的一些必要参数
<span style="color:#000000">./kafka-producer-perf-test.sh
--topic 指定topic
--num-records 指定生产数据量
--throughtput 指定吞吐量
--record-size record数据大小
--producer-props key=value 指定producer配置</span>一个实例如下：
<span style="color:#000000">./kafka-producer-perf-test.sh
--topic louisvv
--num-records 5000000
--throughtput -1
--record-size 200
--producer-props bootstrap.servers=192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092 acks=1</span>测试参数
除了测试acks以及replication对kafka producer的吞吐量外，还对其他参数进行测试。
参数列表如下
| 参数 | 参数说明 |
| acks | 数据发送确认机制 |
| batch-size | 批处理大小 |
| record-size | 数据长度 |
| num-records | 数据条数 |
| replication | topic备份数 |
| partition | topic分区数 |
默认设置
1.以5000万数据测试结果为准，该结果更加具有代表性
2.测试其他参数时，默认设置acks=1，partition数为5，replication数为2
测试结果分析
acks
分别设置kafka producer acks参数为0、1、all，进行测试
测试结果如下：
| 数据（万） | acks | 平均吞吐量 （条/秒） |
平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000 | 0 | 627045.7367 | 250.83 | 119.6 |
| 5000 | 1 | 771771.6791 | 202.89 | 147.2 |
| 5000 | all | 219516.7996 | 721.08 | 41.87 |
图表如下：
结论：
1.在不考虑数据丢失等情况下，设置acks=1时，吞吐量最大，约为acks=0的1.23倍，约为acks=all的3.51倍
2.在保证数据不丢失的情况下，需要选择使用acks=all，但吞吐量会明显降低
replication数
设置Kafka的replication-factor为2、3，进行测试
测试结果如下:
| 数据（万） | replication | 平均吞吐量 （条/秒） |
平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000 | 2 | 627045.7367 | 250.83 | 119.6 |
| 5000 | 3 | 584692.744 | 269.28 | 111.52 |
图表如下：
结论：
replication数越多，吞吐量越低
batch大小
分别设置Kafka的batch-size批处理大小为1000、5000、8000、10000、100000、500000、550000、600000进行测试
测试结果：
| 数据 （万） |
acks | batch大小 | 平均吞吐量 （条/秒） |
平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000 | 1 | 1000 | 63177.41989 | 2116.31 | 12.05 |
| 5000 | 1 | 5000 | 284257.2642 | 539.31 | 54.22 |
| 5000 | 1 | 8000 | 416545.1743 | 369.21 | 79.45 |
| 5000 | 1 | 10000 | 480833.9584 | 324.23 | 91.71 |
| 5000 | 1 | 20000 | 635332.0881 | 246.09 | 121.18 |
| 5000 | 1 | 50000 | 949180.8569 | 158.87 | 181.04 |
| 5000 | 1 | 100000 | 1167051.794 | 112.02 | 222.6 |
| 5000 | 1 | 500000 | 1238696.891 | 78.08 | 236.26 |
| 5000 | 1 | 550000 | 1206127.126 | 85.54 | 230.05 |
| 5000 | 1 | 600000 | 1139575.166 | 85.97 | 217.36 |
折线图如下：
结论：
batch-size大小达到阈值时，会达到吞吐量峰值
当batch-size大小超过阈值后，并不会提升性能
压缩
分别设置Kafka的压缩格式为lz4、snappy、gzip，进行测试
测试结果：
| 数据 （万） |
压缩格式 | 平均吞吐量（条/秒） | 平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000 | lz4 | 1203833.004 | 6.6 | 229.61 |
| 5000 | snappy | 1310719.06 | 7.35 | 250 |
| 5000 | gzip | 198008.8233 | 4.29 | 37.77 |
| 5000 | 无 | 627045.7367 | 250.83 | 119.6 |
条形图如下：
结论：
1.使用snappy压缩格式，吞吐量最高
2.启用压缩的平均延时远小于不启用压缩的平均延时
3.Gzip压缩格式，吞吐量最低，比默认不使用压缩吞吐量还低
record-size
分别设置record-size大小为100、200、500、1000进行测试
测试结果：
| 数据 （万） |
消息长度 （bytes） |
平均吞吐量（条/秒） | 平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000 | 100 | 1047032.709 | 274.06 | 99.85 |
| 5000 | 200 | 627045.7367 | 250.83 | 119.6 |
| 5000 | 500 | 270552.5224 | 240.7 | 129.01 |
| 5000 | 1000 | 140846.6574 | 231.52 | 134.32 |
图表如下：
结论：
随着消息长度的增加，吞吐量逐渐减小，但平均吞吐速率会增大
分区
分别设置partition为1、3、5进行测试
| 数据 （万） |
平均吞吐量（条/秒） | 平均延时（毫秒） | 平均吞吐速率（MB/S） |
| 5000w | 627045.7367 | 250.83 | 119.6 |
| 5000w | 581320.9938 | 271.2 | 110.88 |
| 5000w | 351456.7884 | 451.9 | 67.04 |
图表如下：
结论：
分区数越多，吞吐量越大
Kafka Consumer吞吐量测试
测试背景
需要对Kafka Consumer在不同参数下的吞吐量
性能指标
平均吞吐量（条/秒）、平均延时（毫秒）、平均吞吐率速率（MB/秒）
测试方法
使用Kafka基准测试工具kafka-consumer-perf进行测试
这个工具位于kafka/bin目录下
这里仅简单介绍一下该工具的一些必要参数
<span style="color:#000000">./kafka-consumer-perf-test.sh
--topic 指定topic
--threads 指定线程数
--messages 指定消费数据条数
--broker-list kafka broker列表</span>一个实例如下：
<span style="color:#000000">./kafka-consumer-perf-test.sh
--topic louisvv
--threads 1
--messages 5000000
--broker-list 192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092</span>测试参数
测试参数列表如下
注意：replication并不会影响consumer的吞吐率，因为consumer只会从每个partition的leader读数据，而与replicaiton无关
| 参数 | 参数说明 |
| threads | 线程数 |
| fetch-size | 拉取数据大小 |
| num-records | 数据条数 |
| replication | topic备份数 |
| partition | topic分区数 |
默认设置
1.以5000万数据测试结果为准，该结果更加具有代表性默认设置
2.测试其他参数时，partition数为5，replication数为2
测试结果分析
分区
分别设置partition为1、3、5进行测试
测试结果：
| 数据 （万） |
partition | 平均吞吐量（条/秒） | 平均吞吐速率（MB/S） |
| 5000 | 1 | 2371936.86 | 452.4103 |
| 5000 | 3 | 2907150.765 | 554.495 |
| 5000 | 5 | 3238761.498 | 600.7541 |
图表如下：
结论：
分区数越多，吞吐量越高
fetch-size
分别设置record-size大小为50000、100000、200000、300000、400000、450000、500000、550000、600000行测试
测试结果如下：
| 数据 （万） |
fetch-size | 平均吞吐量 （条/秒） |
平均吞吐速率 （MB/S） |
| 5000 | 50000 | 1400249.552 | 259.3288 |
| 5000 | 100000 | 1792191.871 | 332.445 |
| 5000 | 200000 | 2990615.049 | 552.0419 |
| 5000 | 300000 | 3053828.071 | 564.4809 |
| 5000 | 400000 | 3373830.567 | 624.0051 |
| 5000 | 450000 | 3593015.45 | 665.9499 |
| 5000 | 500000 | 3651258.507 | 676.8822 |
| 5000 | 550000 | 3246984.869 | 602.0835 |
| 5000 | 600000 | 3069380.54 | 569.1356 |
折线图如下：
结论：
fetch-size大小达到一定阈值时，会达到吞吐量峰值，当fetch-size超过阈值后，不会提升性能
replication
设置Kafka的replication-factor为2、3，进行测试
测试结果如下：
| 数据 （万） |
replication | 平均吞吐量 （条/秒） |
平均吞吐速率 （MB/S） |
| 5000 | 3 | 3070336.69 | 585.6202 |
| 5000 | 2 | 3327792.28 | 617.277 |
图表如下：
结论：
分区数越少，吞吐量越大
线程数
设置Kafka的consumer线程数为1、3、5、10、20、30，进行测试
测试结果：
| 数据 （万） |
threads | 平均吞吐量 （条/秒） |
平均吞吐速率 （MB/S） |
| 5000 | 1 | 3238761.498 | 600.7541 |
| 5000 | 3 | 3398817.212 | 630.415 |
| 5000 | 5 | 3229765.519 | 599.0854 |
| 5000 | 10 | 3234152.652 | 599.9312 |
| 5000 | 20 | 3414602.677 | 633.3892 |
| 5000 | 30 | 3367910.548 | 624.6824 |
| 5000 | 40 | 3392590.582 | 629.2721 |
图表如下：
结论：
提高consumer线程数，对吞吐量性能影响并不明显
注意：
1.不同环境下，测试结果不相同，请以实际情况为准
2.测试结果可能存在误差，请谅解，请以实际情况为准
欢迎大家指出问题
亲，看完了点个赞呀！！