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、從測試看,虛擬機器的效能能夠承擔線上請求。但虛擬機器效能不穩定,需要非常謹慎。