kafka性能基准测试

转载请注明出处：http://www.cnblogs.com/xiaodf/

一、测试环境

该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的相似。

二、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

执行命令：

一、建立topic

bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-one --partitions 6--replication-factor 1

二、生产数据

(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

执行命令：

一、建立topic

bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-one-part  --partitions 12 --replication-factor 1

二、生产数据

(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

一、建立topic

bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-two  --partitions 6 --replication-factor 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

一、异步产生数据

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

运行命令：

一、建立topic

bin/kafka-topics.sh--create --zookeeper localhost:2181/kafka --topic test-rep-two_2  --partitions 6 --replication-factor 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

三、异步产生数据

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

 

运行命令：

一、生成数据

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

运行命令：

一、生成数据

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

三、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

 

四、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.1 Producer

(1) 建立具备多个partition的topic，生产数据，观察partition在broker集群的分布及数据量大小情况。若数据均匀分布，producer负载均衡功能良好。

(2) 开发本身的分区规则，查看分区情况

6.2 Consumer

(1) 开启多个Consumer属于同一个Consumer Group，消费同一个topic数据，查看各Consumer消费数据量是否均衡。

(2) 消费过程当中挂掉其中一个Consumer，查看数据消费量变化。

七、端到端延迟(待定)

上文中讨论了吞吐率，那消息传输的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）