kafka性能測試

                        Kafka 壓力測試文檔算法

1        概述

1.1   測試背景

在雲平臺研發SR IAD的過程當中,出現SR IAD對硬件資源消耗較爲嚴重的狀況,其中在雲平臺研發中利用Kafka軟件對流式數據進行數據處理。咱們針對Kafka高吞吐量的特性,對kafka進行壓力測試。bootstrap

1.2   測試目標

測試kafka的吞吐性能(Producer/Consumer性能)。咱們主要對分區、磁盤和線程等影響因素進行測試。緩存

2        測試條件

6臺配置相同的服務器搭建的兩套相同的集羣環境安全

2.1測試環境服務器

硬件條件網絡

 

序號session

硬件架構

配置併發

備註app

1

CPU

E5-2640v2 *2

 

2

內存

128G

 

3

硬盤

共掛載15塊磁盤,剩餘空間10T左右

 

4

網絡

Intel I350 Gigabit Network Connection *4

Intel 82599ES 10-Gigabit SFI/SFP+ Network Connection *2

Intel I350 Gigabit Fiber Network Connection *2

使用

萬兆網卡

5

Kafka

3臺單磁盤服務組成的kafka集羣

 

 

軟件版本:

序號

軟件

版本

備註

1

CentOS

7.3

 

2

Hadoop

2.7.3

 

3

HBase

1.1.7

 

4

Spark

1.6.2

 

5

Elastic Search

2.4.1

 

6

Scala

2.11.8

 

7

Kafka

2.11-0.10.0.1

 

8

Flume

1.7

 

 

系統架構:

 

Kafka默認配置:(CDH裏的配置)

(1)  broker中默認配置

1)網絡和io操做線程配置

 # broker處理消息的最大線程數 (通常不須要修改)

num.network.threads=3

# broker處理磁盤IO的線程數

num.io.threads=8

2)log數據文件刷盤策略

     爲了大幅度提升producer寫入吞吐量,須要按期批量寫文件

     #每當producer寫入10000條消息時,刷數據到磁盤

log.flush.interval.messages=10000

# 每間隔1秒鐘時間,刷數據到磁盤

log.flush.interval.ms=1000

3)日誌保留策略配置

# 保留三天,也能夠更短

log.retention.hours=72

# 段文件配置1GB,有利於快速回收磁盤空間,重啓kafka加載也會加快

log.segment.bytes=1073741824

4)Replica相關配置

replica.lag.time.max.ms:10000

replica.lag.max.messages:4000

num.replica.fetchers:1

#用來控制Fetch線程的數量。

default.replication.factor:1

#自動建立topic時默認的Replica數量,通常建議在2~3爲宜。

5)其餘

num.partitions:1

#分區數量

queued.max.requests:500

#用於緩存網絡請求的隊列的最大容量

compression.codec:none

#Message落地時是否採用以及採用何種壓縮算法。

in.insync.replicas:1

#指定每次Producer寫操做至少要保證有多少個在ISR的Replica確認,通常配合request.required.acks使用。太高可能會大幅下降吞吐量。

(2)  producer 配置

buffer.memory:33554432 (32m)

#在Producer端用來存放還沒有發送出去的Message的緩衝區大小。

compression.type:none

#生產者生成的全部數據壓縮格式,默認發送不進行壓縮。若啓用壓縮,能夠大幅度的減緩網絡壓力和Broker的存儲壓力,但會對cpu 形成壓力。

linger.ms:0

#Producer默認會把兩次發送時間間隔內收集到的全部Requests進行一次聚合而後再發送,以此提升吞吐量,這個參數爲每次發送增長一些delay,以此來聚合更多的Message。

batch.size:16384

#Producer會嘗試去把發往同一個Partition的多個Requests進行合併,batch.size指明瞭一次Batch合併後Requests總大小的上限。若是這個值設置的過小,可能會致使全部的Request都不進行Batch。

acks:1

#設定發送消息後是否須要Broker端返回確認。

0: 不須要進行確認,速度最快。存在丟失數據的風險。

1: 僅須要Leader進行確認,不須要ISR進行確認。是一種效率和安全折中的方式。

all: 須要ISR中全部的Replica給予接收確認,速度最慢,安全性最高,可是因爲ISR可能會縮小到僅包含一個Replica,設置參數爲all並不能必定避免數據丟失。

(3)  Consumer

num.consumer.fetchers:1

#啓動Consumer的個數,適當增長能夠提升併發度。

fetch.min.bytes:1

#每次Fetch Request至少要獲取多少字節的數據才能夠返回。

#在Fetch Request獲取的數據至少達到fetch.min.bytes以前,容許等待的最大時長。

fetch.wait.max.ms:100

(4)  其餘

zookeeper.session.timeout.ms=6s

message.max.bytes=1000000B

replica.fetch.max.bytes=1MB

num.producers=1

### Number of Producers

num.streams=1

###Number of Consumer Threads

producer.request.timeout.ms=30s

consumer.request.timeout.ms=40s

session.timeout.ms=30s

kafka.log4j.dir=/var/log/kafka

##kafka數據的存放地址

2.2 測試方法

壓力發起:kafka官方提供的自測腳本

4項指標:總共發送消息量(以MB爲單位),每秒發送消息量(MB/second),發送消息總數,每秒發送消息數(records/second)

監控信息:自定義腳原本記錄服務狀況,包括CPU、內存、磁盤、網絡等狀況。

(1)  生產者測試腳本kafka-producer-perf-test.sh

參數說明:

--topic topic名稱,

--num-records 總共須要發送的消息數,

--record-size 每一個記錄的字節數,

--throughput 每秒鐘發送的記錄數,

--producer-props bootstrap.servers=localhost:9092 發送端的配置信息

(2)消費者測試腳本kafka-consumer-perf-test.sh

參數說明:

--zookeeper 指定zookeeper的連接信息,

      --topic 指定topic的名稱,

--fetch-size 指定每次fetch的數據的大小,

--messages 總共要消費的消息個數,

2.2.1 producer 吞吐量測試方法

 

一、基於原有配置下對kafka進行數量級的加壓,選用一臺或三臺客戶機先測試在沒有消費者時的吞吐量。測試影響因素主要包括partitions、磁盤和thread三個主要因素,經過記錄每秒鐘條數(Records/s)、每秒日誌量大小(MB/s)衡量吞吐量,並找到各個因素之間的規律。

注:

(1)  線程數的設置根據cpu內核數設置,本測試環境爲16核(thread <=16)。

(2)  Broker 基於物理環境設置(broker<=3),三個

二、經過修改以上3個影響因素測試kafka吞吐量。

三、測試命令

(1)建立topic

1)./kafka-topics.sh --zookeepr IP:2181 --create --topic test --partitions 3 --replication-factor 1

2)./ppt.sh --topic pc918 --num-records 50000000 --record-size 1000 --throughput 10000000 --threads 3 --producer-props

 bootstrap.servers=192.168.17.57:9092,192.168.17.64:9092,192.168.17.65:9092

注:ppt.sh 基於kafka-producer-perf-test.sh修改,增長了生產者的thread 選項。

2.2.2 consumer 吞吐量測試方法

一、基於原有配置下進行消費,並測試主要影響因素partitions、thread和磁盤等因素,選用一臺或三臺客戶機先測試沒有生產者時的吞吐量。經過記錄Records/second、MB/second衡量吞吐量,並找到各個因素之間的規律。

二、經過修改影響因素測試kafka吞吐量。

三、測試命令

./kafka-consumer-perf-test.sh --zookeeper IP:2181 --topic test1 --fetch-size 1048576 --messages 10000000 --threads 3

2.2.3  消費與吞吐量

    分別在一臺或三臺客戶機同時開啓生產者和消費者測試命令,進行測試

3        測試數據(部分樣例)

3.1 寫入測試(only生產者)

3.1.1     Partition VS. Throughput

      實驗條件:3個Broker,1個Topic, Replication-factor=1,3個磁盤,throughput=1000w,num-records=2000w ,batch-size=16K ,1個客戶端,1個producer

      測試項目:分別測試1,3,6,12,15,20,30,50個partition時的吞吐量

                            表1 partition影響因子

類型

partition

Records/second(avg)

MB/second(avg)

延遲時間(avg)

  延遲時間(max)

partition

1

102760

98

297.65

929

3

283639

270.5

107.1

1965

6

332457

317.06

61.22

1085

9

305838

291.67

39.37

2842

12

344245

328.3

21.68

645

15

349846

333.64

20.51

618

20

349852

333.6

15.06

371

30

349870

333.66

15.47

843

50

346296

330.25

13.07

619

     

當partition的個數爲3時,吞吐量成線性增加,當partition多於broker的個數時增加並不明顯,甚至還有所降低。同時隨着,partition個數的增多,延遲時間逐漸減小,當partition個數在3-6之間延遲時間下降較快,越大延遲時間下降趨於平穩。

 

3.1.2     Replica  VS. Throughput

實驗條件:3個Broker,1個Topic,3個磁盤,throughput=35w,num-records=5000w ,batch-size=16K ,1個客戶端,1個producer

     測試項目:分別測試replication-factor爲1,2,3,6時的吞吐量

                         表2 Repica影響因子

類型

replications

Records/second(avg)

MB/second(avg)

延遲時間(avg)

  延遲時間(max)

replication

1

349870

333.66

12.69

713

2

349846

333.64

10.8

392

3

345077

329.09

36.36

897

6

錯誤

Error while executing topic command : replication factor: 6 larger than available brokers: 3

 

 

  

由表可知,replication-factor的個數應該不大於broker的個數,不然就會報錯。隨着replication-factor 個數的增長吞吐量減少,但並不是是線性降低,由於多個Follower的數據複製是並行進行的,而非串行進行,所以基於數據的安全性及延遲性考慮,最多選擇2-3個副本。

 

3.1.3     Thread  VS. Throughput

實驗條件:3個Broker,1個Topic,3個磁盤,3個partitions , throughput=1000w,num-records=1000w ,batch-size=16K ,1個客戶端,1個producer

測試項目:分別測試thread爲1,2,3,4,5時的吞吐量

                      表3 Thread 影響因子

 

 

類型

partition

thread

Records/second(avg)

MB/second(avg)

延遲時間(avg)

  延遲時間(max)

thread

3

1

265505

253.21

113.79

571

2

559252

533.35

93.75

388

3

730300

696.47

68.96

337

4

722700

689.22

42.49

343

5

740137

705.85

36.88

283

 

由表可知隨着線程數的增長吞吐量不斷增長,當線程數小於分區數時增加較快,大於分區數時增加較慢,並趨於平穩。目前單個客戶端能夠達700MB-800MB/s以上的網速流量。

 

3.1.4     磁盤  VS. Throughput

 實驗條件:3個Broker,1個Topic,throughput=1000w,num-records=1000w ,batch-size=16K ,1個客戶端,1個producer

 測試項目:分別測試磁盤個數爲3,6,9時的吞吐量

                  

表4 磁盤影響因子

類型

partition

磁盤個數

Records/second(avg)

MB/second(avg)

延遲時間(avg)

  延遲時間(max)

磁盤

3

3

265505

253.21

113.79

571

6

6

354886

338.45

58.13

512

9

9

363240

346.41

6.33

409

 

由表可知,磁盤個數的增長與partition的增長具備相關性,並不是越多越好,partition的增長受broker的影響,所以磁盤的個數設置應在broker個數的1-3倍之間較爲合適,同時隨着磁盤個數的增長,平均延遲時間在逐漸減少,所以磁盤的數量會影響平均延遲時間。

3.1.5     Others  VS. Throughput

1、Network線程數

Network線程數即broker處理消息的最大線程數 (通常不須要修改)。

實驗條件:3個Broker,1個Topic,throughput=1000w,num-records=5000w ,batch-size=16K ,1個客戶端,1個producer,9個磁盤,9個partitions

測試項目:分別測試線程個數爲3,8時的吞吐量

表5  Network網絡線程數

net.io.thread

生產者y99_thread

Records/second(avg)

MB/second(avg)

CPU(max%)

3

3

516913

492.97

560.5

6

528966

504

943.2

9

441789

421.32

799.3

8

3

629945

600.76

636

6

554865

529.16

855

9

543371

518.2

859

 

由表所示,增長網絡線程數能夠提升吞吐量,但隨着生產者線程數增長逐漸趨於平穩,此時CPU最大值爲998.2%,對於16核的CPU約佔到10核。

2、測試客戶機的影響

因爲在單個客戶機測試時,網卡硬件條件的限制會影響測試的吞吐量,所以換用3臺客戶機測試,吞吐量的測試結果即爲三個客戶機吞吐總量。分別測試6個磁盤和9個磁盤在不一樣分區和線程數的狀況,測試結果如表6所示。

 

                         表6  客戶機影響因素

topic_partition_thread

66

67

68

總量

Records/second(avg)

MB/second(avg)

Records/second(avg)

MB/second(avg)

Records/second(avg)

MB/second(avg)

Records/second(avg)

MB/second(avg)

p66(3)

439382

419.03

461382

440.01

449458

428.64

1350222

1287.68

p66(6)

471635

449.79

468059

446.38

466409

444.8

1406103

1340.97

p66(12)

145292

138.56

145266

138.54

144017

137.35

434575

414.45

p612(3)

498037

474.97

488181

465.57

584098

557.04

1570316

1497.58

p612(6)

305658

291.5

305255

291.11

305715

291.55

916628

874.16

p612(12)

102037

97.31

102032

97.31

101951

97.23

306020

291.85

p99(3)

473771

451.82

481621

459.31

498658

475.56

1454050

1386.69

p99(6)

207400

197.79

207337

197.73

206322

196.76

621059

592.28

p99(12)

174175

166.11

178429

170.16

177564

169.34

530168

505.61

 

    由表6能夠看出,在三臺測試機下,同時向一個topic產生數據,生產者的數據總量是在增大的。在網絡穩定的狀況下,曾測試3個磁盤3個partition最大吞吐量在18000條左右 ,大小爲1683.31MB/s,如圖1所示。

其中在單個broker上cpu最大上線爲700%-800%,內存利用率爲10%-20%。在單臺測試機狀況下,曾測試單臺測試下最大吞吐爲80w條左右,大小約爲80MB/s,因爲資源限制三臺機器總量可能達不到一臺機器3倍的量。

        

 

                       圖1  3臺機器的吞吐量

 

3、IO線程數

IO線程數即broker處理磁盤IO的線程數

實驗條件:3個Broker,1個Topic,throughput=1000w,num-records=5000w ,batch-size=16K ,3個客戶端,1個producer,6個磁盤,6個partitions

測試項目:分別測試線程個數爲8,12時的吞吐量

 

圖2   線程數爲8

 

                         圖3 線程數爲12

   由圖2,3可知,當線程數增長後,吞吐量有所增長,但增長比較緩和。

四、生產者的個數

    實驗條件:3個Broker,1個Topic,throughput=1000w,num-records=5000w ,batch-size=16K ,3個客戶端,1個producer,9個磁盤,9個partitions

測試項目:分別測試生產者個數爲1,2,3時的吞吐量

 

  表7  不一樣生產者吞吐量

thread

1

2

3

1窗口

1窗口

2窗口

1窗口

2窗口

3窗口

MB

MB

MB

MB/s

MB/s

MB/s

3

629945

600.76

338900

323.2

328357

313.15

209465

199.76

205923

196.38

209129

199.44

6

554865

529.16

354172

337.77

382564

364.84

235881

224.95

236085

225.15

245225

233.87

9

543371

518.2

370090

352.95

359056

342.42

209646

199.93

221790

211.52

209058

199.37

 

      由表7 可知,在同一客戶端下,開啓不一樣的生產者,2個生產者和3個生產的總吞吐量基本等於1個生產者的總量。

  五、壓縮因素

實驗條件:3個Broker,1個Topic,throughput=1000w,num-records=5000w ,batch-size=16K ,1個客戶端,1個producer,9個磁盤,9個partitions

測試項目:分別測試不一樣壓縮類型的吞吐量,kafka支持的壓縮類型包括none、Snappy、gzip、LZ4。

測試命令:

./ppt.sh --topic py --num-records 50000000 --record-size 1000 --throughput 10000000 --threads 3 --producer-props bootstrap.servers=192.168.17.68:9092,192.168.17.69:9092,192.168.17.70:9092 compression.type=gzip

 

經過運行時初始化參數看到修改值生效,如圖所示。

 

                    圖4  初始化參數

                    

表8 壓縮因素

壓縮類型

Records/second(avg)

MB/second(avg)

延遲時間(avg)

延遲時間(max)

耗時

cpu max

cpu avg

none

636472

606

122.56

3281

78s

899

545

Snappy

392233

374.06

50.88

672

80s

670

574

gzip

92653

88.36

2.38

386

8分59s

959.5

522

LZ4

618444

589.79

4

329

81s

887.7

480

由表可知snappy、gzip壓縮能夠大幅度的減緩網絡壓力和Broker的存儲壓力,同時下降平均延遲時間,LZ4壓縮在下降平均延遲時間時最顯著,gzip在生產數據時耗時最大。

3.2  讀取測試(only消費者)

3.2.1     Thread  VS. Throughput

 

實驗條件:3個Broker,1個Topic,3個磁盤,throughput=1000w,num-records=5000w ,1個客戶端

  測試項目:分別測試thread爲1,2,3,6時的吞吐量

                         表9  線程因素

console&thread

Records/second(avg)

MB/second(avg)

        p33(11)

340124

324

        p33(12)

799073

762

        p33(13)

973551

928

        p33(16)

963081

918

 

    由表可知,增長線程數會增長消費者的吞吐量,當小於3個線程時吞吐量增速較快,大於3個的時候趨於大致平穩,單個客戶端消費者的吞吐量可達到928MB/s。同時,消費者吞吐量大於生產者的吞吐量而且處理消息的時間總大於生產者。所以在合理的配置下能夠保證消息被及時處理。

3.2.2 消費者  VS. Throughput

  實驗條件:3個Broker,1個Topic,3個磁盤,throughput=1000w,num-records=5000w ,3個客戶端,即三個消費者

   測試項目:分別測試消費者爲1, 3時的吞吐量

   當消費者個數有1增爲3時,吞吐量由324MB/s增長到1324MB/s。Consumer消費消息時以Partition爲分配單位,當只有1個Consumer時,該Consumer須要同時從3個Partition拉取消息,該Consumer所在機器的I/O成爲整個消費過程的瓶頸,而當Consumer個數增長至3個時,多個Consumer同時從集羣拉取消息,充分利用了集羣的吞吐率。對於同一個組內的消費者只容許一個消費者消費一個partition,不一樣組之間能夠消費相同的partition。

3.2.3 磁盤  VS. Throughput

  實驗條件:3個Broker,1個Topic, throughput=1000w,num-records=5000w ,1個客戶端

  測試項目:分別測試消費者爲3,6,9時的吞吐量

                             表10 磁盤影響因素

console&thread

Records/second(avg)

MB/second(avg)

p36(33)

938827

895

p66(33)

888458

847

p96(33)

259475

247

 

由表看出,磁盤數增長並不能提升吞吐率,反而吞吐率相應降低。所以,在必定broker和partition 下能夠按二者值合理增長磁盤。

Consumer 小結

(1)  Consumer 吞吐率遠大於生產者,所以能夠保證在合理的配置下,消息可被及時處理。

(2)  Consumer 處理消息時所消耗單個broker的CPU通常在70%如下,所佔內存也較小,屬於輕量級進程。

(3)  本實驗在三臺客戶端測得Consumer的最大吞吐量在2617MB/s

 

3.3  生產者&消費者

模擬相似真實的環境,生產消費過程

實驗條件:3個Broker,1個Topic, throughput=1000w,num-records=5000w ,3個客戶端,即三個消費者

    測試項目:分別測試磁盤爲3,6,9時的吞吐量

 

(1)  Producer

            表11 生產者吞吐量

topic

Records/second(avg)

MB/second(avg)

pc36(366)

1023426

976.02

p66(366)

1319431

1258.31

p612(366)

1273905

1214.88

p99(366)

989373

943.54

p918(366)

1159443

1105.73

 

(2)  Consumer

                       表12 消費者吞吐量

topic

Records/second(avg)

MB/second(avg)

pc36(366)

934007

889

p66(366)

2259154

2153

p612(366)

1982417

1889

p99(366)

649876

618

p918(366)

1313163

1817

 

由producer與consumer兩表,測得生產的最大吞吐量爲1258.31MB/s,消費最大吞吐量爲2153MB/s。由此看出,與單生產、單消費時的吞吐量大致至關,所用CPU及內存量並未顯著上升。

相關文章
相關標籤/搜索