apache kafka系列之效能測試報告(虛擬機器版)
測試方法
在其他虛擬機器上使用 Kafka 自帶 kafka-producer-perf-test.sh 指令碼進行測試 Kafka 寫入效能
嘗試使用 kafka-simple-consumer-perf-test.sh 指令碼測試 Kafka Consumer 效能，但由於獲取到的資料不靠譜，放棄這個測試方法
效能資料
注：Gzip 和 Snappy 的傳輸速度 MB/S 是通過壓縮前資料計算的，壓縮後的實際傳輸量並沒有超過百兆網絡卡上限
|
單條訊息大小 |
batch size/條 |
執行緒數 |
壓縮方式 |
傳輸速度 MB/S |
傳輸速度 Message/S |
|
0~1000 (avg 500) |
200 |
10 |
不壓縮 |
11.1513 (約為百兆網絡卡上線) |
23369.8916 |
|
0~1000 (avg 500) |
200 |
10 |
Gzip |
14.0450 |
29425.1878 |
|
0~1000 (avg 500) |
200 |
10 |
Snappy |
32.2064 |
67471.7850 |
|
0~100（avg 50） |
200 |
10 |
不壓縮 |
5.3654 |
111399.5121 |
|
0~100（avg 50） |
200 |
10 |
Gzip |
2.6479 |
54979.4926 |
|
0~100（avg 50） |
200 |
10 |
Snappy |
4.4217 |
91836.6410 |
|
0~1800 (avg 900) 仿線上資料量大小 |
200 |
10 |
不壓縮 |
11.0518 (約為百兆網絡卡上線) |
12867.3632 |
|
0~1800 (avg 900) 仿線上資料量大小 |
200 |
10 |
Gzip |
17.3944 |
20261.3717 |
|
0~1800 (avg 900) 仿線上資料量大小 |
200 |
10 |
Snappy |
31.0658 |
36174.2150 |
|
以下資料為第二天測試資料 |
|||||
|
0~100（avg 50） |
200 |
10 |
不壓縮 |
1.8482 |
38387.7159 |
|
0~100（avg 50） |
200 |
10 |
Gzip |
1.3591 |
28219.0930 |
|
0~100（avg 50） |
200 |
10 |
Snappy |
2.0213 |
41979.7658 |
|
0~100（avg 50） |
200 |
50 |
不壓縮 |
2.0900 |
43402.7778 |
|
0~100（avg 50） |
200 |
50 |
Gzip |
1.4639 |
30387.7477 |
|
0~100（avg 50） |
200 |
50 |
Snappy |
2.0871 |
43323.8021 |
|
0~1000 (avg 500) |
200 |
10 |
不壓縮 |
9.8287 |
20594.3530 |
|
0~1000 (avg 500) |
200 |
10 |
Gzip |
13.0659 |
27386.0058 |
|
0~1000 (avg 500) |
200 |
10 |
Snappy |
20.1827 |
42265.4269 |
|
0~1000 (avg 500) |
200 |
1 |
不壓縮 |
7.0980 |
14885.6041 |
|
0~1000 (avg 500) |
200 |
1 |
Gzip |
7.4438 |
15587.7356 |
|
0~1000 (avg 500) |
200 |
1 |
Snappy |
15.3256 |
32088.3070 |
測試結論
1、線上的實際message平均大小略小於1k，在這種情況下(對應 0~1800 的test case)，虛擬機器可以應對每秒上萬條寫入請求。測試環境下，網路頻寬是其瓶頸。通過壓縮可以繞過瓶頸，Snappy演算法可以處理36000+條請求每秒
2、在使用小資料進行測試時，Kafka每秒可以處理10萬條左右資料，網路和IO都不是瓶頸，說明Kafka在虛擬機器上處理寫入請求的上限約為10萬條每秒。
3、第二天的測試在相同條件下與第一天差距很大(0~100 大小資料，10執行緒，batch size 200)，第二天在不壓縮情況下只有第一天的三分之一的處理能力，snappy壓縮情況下也只有二分之一處理能力，說明虛擬機器的效能不夠穩定。
4、生產者執行緒數對比，說明在網路和IO及Kafka處理能力沒有達到瓶頸時，更多的執行緒能夠增加寫入速度，但是增長不明顯。
測試推論
1、虛擬機器上的Kafka最高也可以處理10萬條請求，物理機的處理能力強得多，應當超過10萬條每秒的處理能力。對應線上平均資料大小接近1K，處理資料流量能力不會低於100MB/S，接近千兆網絡卡上限。說明物理機上，在遇到網路頻寬瓶頸前，Kafka效能應當不會是瓶頸。
2、虛擬機器測試是在單topic 單replication 的情況下測試的。無法確定在多個replication時效能下降情況。從網上查詢看，效能下降不是很明顯。
3、從測試看，虛擬機器的效能能夠承擔線上請求。但虛擬機器效能不穩定，需要非常謹慎。