轉載請注明出處：http://www.cnblogs.com/xiaodf/
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、端到端延遲(待定)
上文中討論了吞吐率，那消息傳輸的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）