kafka基准测试
来源:互联网 发布:alibaba的json jar包 编辑:程序博客网 时间:2024/05/17 04:53
1、测试环境
该benchmark用到了六台机器,机器配置如下
l IntelXeon 2.5 GHz processor with six cores
l Six7200 RPM SATA drives
l 32GB ofRAM
l 1GbEthernet
这6台机器其中3台用来搭建Kafka broker集群,另外3台用来安装Zookeeper及生成测试数据。6个drive都直接以非RAID方式挂载。实际上kafka对机器的需求与Hadoop的类似。
2、producer吞吐率
该项测试只测producer的吞吐率,也就是数据只被持久化,没有consumer读数据。总数据条数50 million。测试过程中可以改变不同参数的取值,来测试特定参数对性能的影响。
使用官方提供的测试工具kafka-producer-perf-test.sh来测试。
kafka-producer-perf-test.sh中参数说明:
参数
说明
messages
生产者发送总的消息数量
message-size
每条消息大小
batch-size
每次批量发送消息的数量
topics
生产者发送的topic
threads
生产者使用几个线程同时发送
broker-list
安装kafka服务的机器ip:port列表
producer-num-retries
一个消息失败发送重试次数
request-timeout-ms
一个消息请求发送超时时间
2.1 线程数
创建一个6个分区,没有备份的topic,设置不同的线程数生产相同量的数据,查看性能变化。运行结果如下表所示,(可测多组用折线图表示)。
操作
线程
partition
replication
Records/second
MB/second
1
1
6
1
99837.8633
9.5213
2
3
6
1
261730.7628
24.9606
3
6
6
1
306865.1757
29.2649
执行命令:
1、创建topic
bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-one --partitions 6--replication-factor 1
2、生产数据
(1) 一个进程
bin/kafka-producer-perf-test.sh--messages 50000000 --topicstest-rep-one --threads 1 --broker-list m103:9092,m105:9092
结果:
start.time,end.time, compression, message.size, batch.size, total.data.sent.in.MB, MB.sec,total.data.sent.in.nMsg, nMsg.sec
2015-05-2611:44:12:728, 2015-05-26 11:52:33:540, 0, 100, 200, 4768.37, 9.5213, 50000000,99837.8633
(2) 3个进程
bin/kafka-producer-perf-test.sh--messages 50000000 --topicstest-rep-one --threads 3 --broker-list m103:9092,m105:9092
(2) 6个进程
bin/kafka-producer-perf-test.sh--messages 50000000 --topicstest-rep-one --threads 6 --broker-list m103:9092,m105:9092
2.2 分区数
新建topic,改变分区数,生产等量数据,查看性能变化。一般情况下,对于大数据量,partition的数量大于等于broker的数据。(可测多组用折线图表示)
操作
进程
partition
replication
Records/second
MB/second
1
1
6
1
99837.8633
9.5213
2
1
12
1
84516.7081
8.0601
执行命令:
1、创建topic
bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-one-part --partitions 12 --replication-factor 1
2、生产数据
(1) 一个进程
bin/kafka-producer-perf-test.sh--messages 50000000 --topicstest-rep-one-part --threads 1 --broker-list m103:9092,m105:9092 --request-timeout-ms 10000
结果:
2015-06-0115:36:58:224, 2015-06-01 15:46:49:823, 0, 100, 200, 4768.37, 8.0601, 50000000,84516.7081
初步结论:分区数越多,单线程生产者吞吐率越小。
Throughputincreases very markedly at first as more brokers and disks on them starthosting different partitions. Once all brokers and disks are used though,adding additional partitions does not seem to have any effect.
2.3 备份数
新建topic,改变分区数,生产等量数据,查看性能变化。可以推断吞吐性能会随备份数增多而减少。(可测多组用折线图表示)
操作
线程
partition
replication
Records/second
MB/second
1
1
6
0
99837.8633
9.5213
2
2
6
2
86491.7227
8.2485
1、创建topic
bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-two --partitions 6 --replication-factor 2
2、生成数据
bin/kafka-producer-perf-test.sh--messages50000000 --topics test-rep-two --threads 2 --broker-list m103:9092,m105:9092
结果:
2015-05-2615:26:39:899, 2015-05-26 15:36:17:989, 0, 100, 200, 4768.37, 8.2485, 50000000,86491.7227
初步结论:备份数越多,吞吐率越低。
2.4 broker数
增加broker的个数,查看性能变化。
操作
线程
Broker数
partition
replication
Records/second
MB/second
1
2
1
6
2异步
248172.2117
23.6675
2
2
2
6
2异步
251764.8718
24.0102
1、异步产生数据
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2--batch-size 3000 --broker-list m103:9092,m105:9092 --request-timeout-ms 100000
结论:
增加broker的个数,吞吐量增加。
2.5 同步异步
分别以同步异步方式,生产等量数据,查看性能变化。
操作
线程
partition
replication
Records/second
MB/second
1
2
6
2同步
68860.1849
6.5670
2
2
6
2异步
172405.4701
16.4419
运行命令:
1、创建topic
bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-two_2 --partitions 6 --replication-factor 2
2、同步产生数据
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2 --broker-listm103:9092,m105:9092 --sync
结果:
2015-06-0210:38:16:846, 2015-06-02 10:50:22:955, 0, 100, 200, 4768.37, 6.5670, 50000000,68860.1849
3、异步产生数据
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2--batch-size 5000 --broker-list m103:9092,m105:9092 --request-timeout-ms 100000
结果:
2015-06-0210:36:12:492, 2015-06-02 10:41:02:506, 0, 100, 5000, 4768.37, 16.4419,50000000, 172405.4701
结论:异常产生数据比同步产生数据吞吐率高近3倍。
2.6 批处理大小
异步生产等量数据,改变批处理量大小,查看性能变化。
操作
线程
partition
replication
批大小
Records/second
MB/second
1
2
6
2
200
86491.7227
8.2485
2
2
6
2
1000
187594.7353
17.8904
3
2
6
2
2000
244479.6495
23.3154
4
2
6
2
3000
248172.2117
23.6675
5
2
6
2
4000
242217.5501
23.0997
6
2
6
2
5000
172405.4701
16.4419
运行命令:
1、生成数据
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2--batch-size 1000 --broker-list m103:9092,m105:9092--request-timeout-ms 100000
结果:
2.7 消息长度
操作
线程
消息长度(bytes)
Records/second
MB/second
1
2
100
248172.2117
23.6675
2
2
200
132873.0610
25.3435
3
2
500
79277.1195
37.8023
4
2
1000
39015.5290
37.2081
异步产生数据:
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2--batch-size 3000 --broker-list m103:9092,m105:9092 --request-timeout-ms 100000 --message-size200
结论:
上面的所有测试都基于短消息(payload100字节),而正如上文所说,短消息对Kafka来说是更难处理的使用方式,可以预期,随着消息长度的增大,records/second会减小,但MB/second会有所提高。下图是records/second与消息长度的关系图。
正如我们所预期的那样,随着消息长度的增加,每秒钟所能发送的消息的数量逐渐减小。但是如果看每秒钟发送的消息的总大小,它会随着消息长度的增加而增加,如下图所示。
从上图可以看出,当消息长度为10字节时,因为要频繁入队,花了太多时间获取锁,CPU成了瓶颈,并不能充分利用带宽。但从100字节开始,我们可以看到带宽的使用逐渐趋于饱和(虽然MB/second还是会随着消息长度的增加而增加,但增加的幅度也越来越小)。
2.8 数据压缩
分别以同步异步方式,生产等量数据,查看性能变化。
操作
进程
partition
压缩
Records/second
MB/second
1
2
6
无(0)
87677.3054
8.3616
2
2
6
GZIP(1)
84312.6245
8.0407
3
2
6
Snappy(2)
140113.7163
13.3623
运行命令:
1、生成数据
bin/kafka-producer-perf-test.sh--messages 50000000 --topics test-rep-two_2 --threads 2 --compression-codec 1 --batch-size3000 --broker-list m103:9092,m105:9092 --request-timeout-ms 100000
结果:
start.time,end.time, compression, message.size, batch.size, total.data.sent.in.MB, MB.sec,total.data.sent.in.nMsg, nMsg.sec
2015-06-0214:17:29:393, 2015-06-02 14:23:26:246, 2, 100, 3000, 4768.37, 13.3623,50000000, 140113.7163
3、consumer吞吐率
需要注意的是,replicationfactor并不会影响consumer的吞吐率测试,因为consumer只会从每个partition的leader读数据,而与replicaiton factor无关。同样,consumer吞吐率也与同步复制还是异步复制无关。
该测试从有6个partition,3个replication的topic消费50 million的消息。使用官方提供的测试工具kafka-consumer-perf-test.sh来测试。
kafka-consumer-perf-test.sh中参数说明:
参数
说明
zookeeper
zookeeper端口配置
messages
消费者消费消息总数量
topic
消费者需要消费的topic
threads
消费者使用几个线程同时消费
group
消费者组名称
socket-buffer-sizesocket
缓冲大小
fetch-size
每次向kafka broker请求消费大小
consumer.timeout.ms
消费者去kafka broker拿去一条消息超时时间
可以看到,Kafka的consumer是非常高效的。它直接从broker的文件系统里读取文件块。Kafka使用sendfile API来直接通过操作系统直接传输,而不用把数据拷贝到用户空间。该项测试实际上从log的起始处开始读数据,所以它做了真实的I/O。
在生产环境下,consumer可以直接读取producer刚刚写下的数据(它可能还在缓存中)。实际上,如果在生产环境下跑I/O stat,你可以看到基本上没有物理“读”。也就是说生产环境下consumer的吞吐率会比该项测试中的要高。
3.1 Consumer数
将上面的consumer复制到3台不同的机器上,并且并行运行它们(从同一个topic上消费数据)。consumer的吞吐率几乎线性增涨。
Consumer
Records/second
MB/second
1
3
运行命令:
bin/kafka-consumer-perf-test.sh--zookeeper localhost:2181/kafka --messages 50000000 --topic test-rep-two_2--threads 1
结果:
start.time,end.time, compression, message.size, batch.size, total.data.sent.in.MB, MB.sec,total.data.sent.in.nMsg, nMsg.sec
3.2 分区数
消费等量不同topic的数据,消费者数相同,不同topic分区数不同,查看性能变化。
操作
线程
partition
replication
Records/second
MB/second
1
1
6
3
2
1
12
3
3.3 线程数
消费同一个topic的数据,消费者数相同,改变线程数,查看性能变化。一般线程数大于等于分区数。
操作
线程
partition
replication
Records/second
MB/second
1
1
6
3
2
3
6
3
4、Producer and Consumer
上面的测试只是把producer和consumer分开测试,而该项测试同时运行producer和consumer,这更接近使用场景。实际上目前的replication系统中follower就相当于consumer在工作。
该项测试,在具有6个partition和3个replica的topic上同时使用1个producer和1个consumer,并且使用异步复制。
Producer
Consumer
Records/second
MB/second
1
1
可以看到,该项测试结果与单独测试1个producer时的结果几乎一致。所以说consumer非常轻量级。
6、负载均衡
6.1 Producer
(1) 创建具有多个partition的topic,生产数据,观察partition在broker集群的分布及数据量大小状况。若数据均匀分布,producer负载均衡功能良好。
(2) 开发自己的分区规则,查看分区状况
6.2 Consumer
(1) 开启多个Consumer属于同一个Consumer Group,消费同一个topic数据,查看各Consumer消费数据量是否均衡。
(2) 消费过程中挂掉其中一个Consumer,查看数据消费量变化。
7、故障恢复
8、端到端延迟(待定)
上文中讨论了吞吐率,那消息传输的latency如何呢?也就是说消息从producer到consumer需要多少时间呢?该项测试创建1个producer和1个consumer并反复计时。结果是,2 ms (median), 3ms (99th percentile,14ms (99.9th percentile)。(这里并没有说明topic有多少个partition,也没有说明有多少个replica,replication是同步还是异步。实际上这会极大影响producer发送的消息被commit的latency,而只有committed的消息才能被consumer所消费,所以它会最终影响端到端的latency)
9、broker配置
见配置文件。
- kafka基准测试
- kafka性能基准测试
- 基准测试
- Apache Kafka基准测试:每秒写入2百万(在三台廉价机器上)
- Java基准测试
- 基准测试程序
- hadoop基准测试
- Hadoop Gridmix基准测试
- 运行hadoop基准测试
- 基准测试工具
- hadoop基准测试---新手入门
- 运行hadoop基准测试
- Oracle 基准测试工具
- hadoop基准测试
- php基准测试
- hbase基准测试
- Hadoop 集群基准测试
- MySQL基准测试
- php提示超过30秒最长执行时间错误的解决方法
- Turtlebot—kobuki安装启动流程
- Android开发之design库学习
- 用C++写线性容器Vector
- iOS中判断字符串中的字符
- kafka基准测试
- Linux命令----分析CPU的瓶颈
- 懒癌治疗仪 - 写在前面
- [算法学习]给定一个整型数组,找出两个整数为指定整数的和(1)
- TCP的哪些事(下)
- Linux tcpdump的命令大全
- hadoop 2.6.3 BlockPlacementPolicy分析
- python中if __name__ == '__main__': 的解析
- Android Audio System 之二:AudioFlinger