Kafka測試及性能調優詳細總結

Kafka性能測試html

 

 

測試背景python

 

因爲業務需求,針對kafka在不一樣參數下的性能進行測試。從而進行kafka性能調優vim

 

測試目標緩存

 

測試kafka 0.8n的性能(Producer/Consumer性能)。當消息大小、批處理大小、壓縮等參數變化時對吞吐率的影響。服務器

 

測試環境多線程


軟件版本:kafka 0.8.1.1
硬件環境:3臺多雲服務組成的kafka集羣。各服務器CPU4核,內存16G,配置以下:app

 

 

服務器IP:異步

203.150.54.215socket

203.150.54.216工具

203.150.54.217

 

測試方法

 

使用kafka官方提供的kafa-perf工具作性能測試

 

測試步驟


1、測試環境準備
一、測試工具kafka-perf的準備

cp kafka-perf_2.10-0.8.1.1.jar /application/kafka/libs/


二、啓動kafka

cd /application/kafka

vim config/server.properties  #內容見下圖

./bin/kafka-server-start.sh --daemon config/server.properties

三、測試集羣可靠性

建立一個主題,複製因子爲3.

[root@203-150-54-215 kafka]# bin/kafka-topics.sh --create –zookeeper 203.150.54.215:21203,203.150.54.216:21203,203.150.54.217:21203 --replication-factor 3 --partitions 3 --topic 88

Created topic "88".

查看建立的主題分區狀況

[root@203-150-54-215 kafka]# bin/kafka-topics.sh --describe --zookeeper  203.150.54.215:21203 --topic 88

Topic:88        PartitionCount:3        ReplicationFactor:3     Configs:

        Topic: 88       Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 3,1,2

        Topic: 88       Partition: 1    Leader: 1       Replicas: 1,2,3 Isr: 1,2,3

        Topic: 88       Partition: 2    Leader: 2       Replicas: 2,3,1 Isr: 2,3,1

在215上啓動生產者

[root@203-150-54-215 kafka]# bin/kafka-console-producer.sh --broker-list 203.150.54.215:21204 --topic 88

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

SLF4J: Defaulting to no-operation (NOP) logger implementation

SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

test

hh

在216上進行消費

[root@203-150-54-216 kafka]#       bin/kafka-console-consumer.sh --zookeeper 203.150.54.216:21203 --topic 88 --from-beginning                

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

SLF4J: Defaulting to no-operation (NOP) logger implementation

SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

 

 

test

hh

從上可知:3個服務器集羣之間連接正常,下面進行性能測試
kafka-producer-perf-test.sh中參數說明:

messages 生產者發送走的消息數量

message-size 每條消息的大小

batch-size 每次批量發送消息的數量

topics 生產者發送的topic

threads 生產者

broker-list 安裝kafka服務的機器ip:porta列表

producer-num-retries 一個消息失敗發送重試次數

request-timeouts-ms 一個消息請求發送超時時間

bin/kafka-consumer-perf-test.sh中參數說明:

zookeeper  zk配置

messages 消費者消費消息的總數量

topic 消費者須要消費的topic

threads 消費者使用幾個線程同時消費

group 消費者組名稱

socket-buffer-sizes socket緩存大小

fetch-size 每次想kafka broker請求消費消息大小

consumer.timeout.ms 消費者去kafka broker拿一條消息的超時時間


2、測試生產者吞吐率
此項只測試producer在不一樣的batch-zie,patition等參數下的吞吐率,也就是數據只被及計劃,沒有consumer讀取數據消費狀況。
生成Topic:
生成不一樣複製因子,partition的topic

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati1-rep1 --partitions 1 --replication-factor 1

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati1-rep2 --partitions 1 --replication-factor 2

 

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati2-rep1 --partitions 2 --replication-factor 1

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati2-rep2 --partitions 2 --replication-factor 2

 

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati3-rep1 --partitions 3 --replication-factor 1

bin/kafka-topics.sh --zookeeper 203.150.54.215:21203 --create --topic test-pati3-rep2 --partitions 3 --replication-factor 2

測試producer吞吐率
調整batch-size,thread,topic,壓縮等參數測試producer吞吐率。
示例:

a)批處理爲1,線程數爲1,複製因子爲1

bin/kafka-producer-perf-test.sh --messages 500000 --message-size 512 --batch-size 1 --topic test-pati1-rep1  --threads 1 --broker-list 203.150.54.215:21204,203.150.54.216:21204,203.150.54.217:21204

 

b)批處理爲5,線程數爲4,複製因子爲2

bin/kafka-producer-perf-test.sh --messages 50000 --message-size 512 --batch-size 5 --topic test-pati1-rep2 --threads 1 --broker-list 203.150.54.215:21204,203.150.54.216:21204,203.150.54.217:21204

c)批處理爲10,線程數爲4,複製因子爲2,不壓縮,sync

bin/kafka-producer-perf-test.sh --messages 50000 --message-size 512 --batch-size 10 --topic test-pati2-rep2 --threads 4 --compression-codec 0 --sync 1 --broker-list 203.150.54.215:21204,203.150.54.216:21204,203.150.54.217:21204

 

d)批處理爲10,線程數爲4,複製因子爲2,gzip壓縮,sync

bin/kafka-producer-perf-test.sh --messages 50000 --message-size 512 --batch-size 10 --topic test-pati2-rep2 --threads 4 --compression-codec 1 --sync 1 --broker-list 203.150.54.215:21204, 203.150.54.216:21204, 203.150.54.217:21204

說明:消息大小統一使用和業務場景中日誌大小相近的512Bype,消息數爲50w或200w條。
 
3、測試消費者吞吐率
測試consumer吞吐率
調整批處理數,線程數,partition數,複製因子,壓縮等進行測試。
示例:

a)批處理爲1,線程數爲1,複製因子爲1

 --messages 500000 --message-size 512 --batch-size 1 --topic test-pati1-rep1  --threads 1 203.150.54.215:bin/kafka-consumer-perf-test.sh--zookeeper2181

 

b)批處理爲5,線程數爲4,複製因子爲2

bin/kafka-consumer-perf-test.sh --messages 50000 --message-size 512 --batch-size 5 --topic test-pati1-rep2 --threads 1  --zookeeper 203.150.54.215:2181

c)批處理爲10,線程數爲4,複製因子爲2,不壓縮,sync

bin/kafka-consumer-perf-test.sh --messages 50000 --message-size 512 --batch-size 10 --topic test-pati2-rep2 --threads 4 --compression-codec 0 --sync 1  --zookeeper 203.150.54.215:2181

 

d)批處理爲10,線程數爲4,複製因子爲2,gzip壓縮,sync

bin/kafka-consumer-perf-test.sh --messages 50000 --message-size 512 --batch-size 10 --topic test-pati2-rep2 --threads 4 --compression-codec 1 --sync 1  --zookeeper 203.150.54.215:2181

 

注:以上測試均使用python腳本多線程測試實現。

測試結果及分析

 

一、 生產者測試結果及分析

調整線程數,批處理數,複製因子等參考,對producer吞吐率進行測試。在測試時消息大小爲512Byte,消息數爲50w,結果以下:

 

 

複製因子

1

2

線程數

批處理

 

 

 

1

1

 

1.8598

0.5878

4

5

 

17.6594

7.2501

4

10

 

26.4221

13.0208

 

 

壓/no

 

 

4

10

 

4.6855

1.9058

4

10

 

3.0945

1.4846

                           Producer吞吐率(MB/s)


調整sync模式,壓縮方式獲得吞吐率數據如表3.在本次測試中msg=512Byte,message=500000,batch_zie=10

 
結果分析:
1)kafka在批處理,多線程,不適用同步複製的狀況下,吞吐率是比較高的,能夠達26MB/s,消息數達17w條/s以上。
2)使用批處理或多線程對提高生產者吞吐率效果明顯。
3)複製因子會對吞吐率產生較明顯影響
   使用同步複製時,複製因子會對吞吐率產生較明顯的影響。複製因子爲2比因子爲1(即無複製)時,吞吐率降低40%左右。


4)使用sync方式,性能有明顯降低。
   使用Sync方式producer吞吐率會有明顯降低
5)壓縮與吞吐率
  使用Gzip及Snappy方式壓縮,吞吐率反而有降低,緣由待分析。而Snappy方式吞吐率高於gzip方式。
6)分區數與吞吐率
   分區數增長生產者吞吐率反而有所降低 
 
2、消費者結果及分析


結果分析:

1)kafka consumer吞吐率在parition,threads較大的狀況下,在測試場景下,最大吞吐率達到了34MB/s
2)複製因子,影響較小。replication factor並不會影響consumer的吞吐率測試, consumer從每一個partition的leader讀數據,而與replication factor無關。一樣,consumer吞吐率也與同步複製仍是異步複製無關。
3)線程數和partition與吞吐率關係

當分區數較大時,增長thread數可顯著提高consumer的吞吐率。
但要注意在分區較大時線程數不改大於分區數,不然會出現No broker partitions consumed by consumer,對提高吞吐率也沒有幫助。

4)批處理數對吞吐率影響

改變批處理數對吞吐率影響不大
5)壓縮與吞吐率

壓縮對吞吐率影響小。

 

附優化後的配置文件:

broker.id=1

listeners=PLAINTEXT://0.0.0.0:6667

advertised.listeners=PLAINTEXT://203.150.54.215:6667

port=6667

host.name=203.150.54.215

 

# Replication configurations

num.replica.fetchers=1

replica.fetch.max.bytes=1048576

replica.fetch.wait.max.ms=500

replica.high.watermark.checkpoint.interval.ms=5000

replica.socket.timeout.ms=30000

replica.socket.receive.buffer.bytes=65536

replica.lag.time.max.ms=10000

replica.lag.max.messages=4000

 

compression.codec:none

controller.socket.timeout.ms=30000

controller.message.queue.size=10

controlled.shutdown.enable=true

default.replication.factor:2

 

# Log configuration

num.partitions=1 

num.recovery.threads.per.data.dir=1

message.max.bytes=1000000

auto.create.topics.enable=true

auto.leader.rebalance.enable=true

log.dirs=/mnt/kafka-logs/kafka00

log.index.interval.bytes=4096

log.index.size.max.bytes=10485760

log.retention.hours=72 #保留三天,也能夠更短

log.flush.interval.ms=10000  #每間隔1秒鐘時間,刷數據到磁盤

log.flush.interval.messages=20000 #log數據文件刷新策略

log.flush.scheduler.interval.ms=2000

log.roll.hours=72

log.retention.check.interval.ms=300000

log.segment.bytes=1073741824 #kafka啓動時是單線程掃描目錄(log.dir)下全部數據文件

 

# ZK configuration

zookeeper.connection.timeout.ms=6000

zookeeper.sync.time.ms=2000

zookeeper.connect=203.150.54.215:2181,203.150.54.216:2182,203.150.54.217:2183

 

# Socket server configuration

num.io.threads=5 #配置線程數量爲cpu核數加1

num.network.threads=8 #配置線程數量爲cpu核數2倍,最大不超過3倍

socket.request.max.bytes=104857600

socket.receive.buffer.bytes=1048576

socket.send.buffer.bytes=1048576

queued.max.requests=500

fetch.purgatory.purge.interval.requests=1000

producer.purgatory.purge.interval.requests=1000

相關文章
相關標籤/搜索