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）