【kafka性能測(cè)試腳本詳解、性能測(cè)試、性能分析與性能調(diào)優(yōu)】

這篇具有很好參考價(jià)值的文章主要介紹了【kafka性能測(cè)試腳本詳解、性能測(cè)試、性能分析與性能調(diào)優(yōu)】。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請(qǐng)大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

Kafka 性能測(cè)試

一、介紹

Apache Kafka 官方提供了兩個(gè)客戶端性能測(cè)試腳本，它們的存放位置如下：

生產(chǎn)者性能測(cè)試腳本：$KAFKA_HOME/bin/kafka-producer-perf-test.sh
消費(fèi)者性能測(cè)試腳本：$KAFKA_HOME/bin/kafka-consumer-perf-test.sh
kafka-producer-perf-test.sh 支持測(cè)試的性能指標(biāo)包括：吞吐量（throughput）、最大時(shí)延（max-latency）、平均時(shí)延（avg-latency）；kafka-consumer-perf-test.sh 同樣支持吞吐量指標(biāo)，還提供了一些消費(fèi)端特有的指標(biāo)，但沒有直接提供時(shí)延信息。

二、使用

2.1 kafka-producer-perf-test.sh

此腳本用于測(cè)試 Kafka 生產(chǎn)消息的性能，可選參數(shù)列表如下，加粗項(xiàng)為常用參數(shù)。
暫時(shí)無法在飛書文檔外展示此內(nèi)容

參數(shù)名	含義
-h, --help	顯示使用幫助并退出
參數(shù)名	指定生產(chǎn)的消息發(fā)往的 topic
-h, --help	指定生產(chǎn)的消息總數(shù)
–topic	如果通過 --payload-file 指定了從文件中獲取消息內(nèi)容，那么這個(gè)參數(shù)的意義是指定文件的消息分隔符，默認(rèn)值為 \n，即文件的每一行視為一條消息；如果未指定 --payload-file 則此參數(shù)不生效
–num-records	限制每秒發(fā)送的最大的消息數(shù)，設(shè)為 -1 表示不限制
–payload-delimeter	直接指定 Producer 配置，格式為 NAME=VALUE，例如 bootstrap.server=127.0.0.1:9092，通過此種方式指定的配置優(yōu)先級(jí)高于 --producer.config
–throughput	指定 Producer 的配置文件，格式參照官方的 config/producer.properties
–producer-props	在測(cè)試結(jié)束后打印更詳盡的指標(biāo)，默認(rèn)為 false
–producer-config	指定事務(wù) ID，測(cè)試并發(fā)事務(wù)的性能時(shí)需要，只有在 --transaction-duration-ms > 0 時(shí)生效，默認(rèn)值為 performance-producer-default-transactional-id
–print-metrics	在測(cè)試結(jié)束后打印更詳盡的指標(biāo)，默認(rèn)為 false
–transactional-id	指定事務(wù) ID，測(cè)試并發(fā)事務(wù)的性能時(shí)需要，只有在 --transaction-duration-ms > 0 時(shí)生效，默認(rèn)值為 performance-producer-default-transactional-id
–transactional-duration-ms	指定事務(wù)持續(xù)的最長(zhǎng)時(shí)間，超過這段時(shí)間后就會(huì)調(diào)用 commitTransaction 來提交事務(wù)，只有指定了 > 0 的值才會(huì)開啟事務(wù)，默認(rèn)值為 0
–record-size	指定每條消息的大小，單位是字節(jié)，和 --payload-file 兩個(gè)中必須指定一個(gè)，但不能同時(shí)指定
–payload-file	指定消息的來源文件，只支持 UTF-8 編碼的文本文件，文件的消息分隔符通過 --payload-delimeter 指定，和 --record-size 兩個(gè)中必須指定一個(gè)，但不能同時(shí)指定

【示例】

bin/kafka-producer-perf-test.sh --topic perf-test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=127.0.0.1:9092 compression.type=lz4

【輸入解釋】
發(fā)送 1000 條大小為 1KB 的消息到地址為 127.0.0.1:9092 的 broker 上的 perf-test 主題，發(fā)送時(shí)不限制吞吐量，并使用 lz4 算法壓縮消息。
執(zhí)行示例命令后，控制臺(tái)輸出一行測(cè)試結(jié)果，如下：

1000 records sent, 3424.657534 records/sec (3.34 MB/sec), 13.61 ms avg latency, 255.00 ms max latency, 13 ms 50th, 20 ms 95th, 255 ms 99th.

【輸出解釋】
成功消費(fèi)了 1000 條消息，吞吐量為 3424.657534 條/秒 (或 3.34 MB/秒)，平均時(shí)延為 13.61 ms，最大時(shí)延為 255.00 ms，50 % 的消息延時(shí)在 13 ms 內(nèi)，95 % 的消息延時(shí)在 20 ms 內(nèi)，99 % 的消息延時(shí)在 255 毫秒內(nèi)。

2.2 kafka-consumer-perf-test.sh

此腳本用于測(cè)試 Kafka 消費(fèi)消息的性能，可選參數(shù)列表如下，加粗項(xiàng)為常用參數(shù)。

參數(shù)名	含義
–bootstrap-server	指定 broker 地址，必選，除非用 --broker-list 代替（不建議）
–topic	指定消費(fèi)的 topic，必選
–version	輸出 Kafka 版本
–consumer.config	指定 Consumer 配置文件
–date-format	指定用于格式化 *.time 的規(guī)則，默認(rèn)為 yyyy-MM-dd HH:mm:ss:SSS
–fetch-size	指定一次請(qǐng)求消費(fèi)的大小，默認(rèn)為 1048576 即 1 MB
–from-latest	如果 Consumer 沒有已經(jīng)建立的 offset，則指定從 log 中最新的位點(diǎn)開始消費(fèi)，而不是從最早的位點(diǎn)開始消費(fèi)
–group	指定 ConsumerGroup ID，默認(rèn)為 perf-consumer-40924
–help	顯示使用幫助并退出
–hide-header	指定后不輸出 header 信息
–messages	指定消費(fèi)的消息數(shù)量，必選
–num-fetch-threads	指定 fetcher 線程的數(shù)量
–print-metrics	指定打印 metrics 信息
–reporting-interval	指定打印進(jìn)度信息的時(shí)間間隔，默認(rèn)為 5000 即 5 秒
–show-detailed-stats	指定每隔一段時(shí)間（由 --reporting-interval 指定）輸出顯示詳細(xì)的狀態(tài)信息
–socket-buffer-size	指定 TCP 的 RECV 大小，默認(rèn)為 2097152 即 2 MB
–threads	指定消費(fèi)的線程數(shù)，默認(rèn)為 10
–timeout	指定允許的最大超時(shí)時(shí)間，即每條消息返回的最大時(shí)間間隔，默認(rèn)為 10000 即 10 秒

【示例】

bin/kafka-consumer-perf-test.sh --bootstrap-server 127.0.0.1:9092 --topic perf_test --messages 1000000 --threads 8 --reporting-interval 1000 --show-detailed

【輸入解釋】
同時(shí)開啟 8 個(gè)消費(fèi)線程，從 127.0.0.1:9092 的 broker 上的 perf-test 主題中消費(fèi) 1000 條消息，每隔 1000 ms = 1 s 打印一次消費(fèi)進(jìn)度信息。最后兩個(gè)參數(shù)在消費(fèi)數(shù)量很小的場(chǎng)景下沒有什么幫助，比如若消費(fèi)數(shù)量只有 1000，命令瞬間就可以執(zhí)行返回；但當(dāng)指定的消費(fèi)數(shù)量很大（如示例中為 1000 萬）時(shí)，需要 10 s 左右才能消費(fèi)完，此時(shí)定時(shí)輸出一下進(jìn)度信息就顯得很有用了。
執(zhí)行示例命令后，控制臺(tái)輸出兩行信息，其中第一行為表頭，接下來的數(shù)行為每秒的進(jìn)度信息，如下：

time, threadId, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg,nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec,fetch.nMsg.sec
2021-03-25 15:57:59:426, 0, 657.2275, 657.2275, 673001,
673001.0000, 1616659078690, -1616659077690, 0.0000, 0.0000

…
【輸出解釋】

time：當(dāng)前時(shí)間，格式由 --date-format 指定
threadId：線程 ID
data.consumed.in.MB：消費(fèi)到的數(shù)據(jù)總大小，單位為 MB
MB.sec：消費(fèi) TPS，即每秒消費(fèi)的消息大小
data.consumed.in.nMsg：消費(fèi)到的總消息數(shù)
nMsg.sec：消費(fèi) TPS，即每秒消費(fèi)的消息條數(shù)
rebalance.time.ms：消費(fèi)者組重平衡的耗時(shí)，單位為 ms，0 表示沒有發(fā)生重平衡
fetch.time.ms：fetch 線程的總耗時(shí)，單位為 ms
fetch.MB.sec：fetch 線程每秒鐘獲取到的消息大小
fetch.nMsg.sec：fetch 線程每秒鐘獲取到的消息數(shù)量
【注意】
若沒有指定 --show-detailed，則輸出信息中的前兩項(xiàng)會(huì)有所不同，如下：

start.time, end.time, data.consumed.in.MB, MB.sec, …

start.time：消費(fèi)開始的時(shí)間，格式由 --date-format 指定
end.time：消費(fèi)結(jié)束的時(shí)間，格式由 --date-format 指定

測(cè)試

producer（生產(chǎn)者）

partitions（分區(qū)）

3個(gè)分區(qū)（partitions）

–replication-factor 4 --partitions 3(test)
1000 條大小為 1KB 的消息

bin/kafka-producer-perf-test.sh --topic test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4

kafka-consumer-perf-test.sh,kafka,kafka,分布式
1000000 條大小為 1KB 的消息

bin/kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4

kafka-consumer-perf-test.sh,kafka,kafka,分布式

–replication-factor 1 --partitions 3(test13)
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

4個(gè)分區(qū)（partitions）

–replication-factor 4 --partitions 4（testpro）
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

–replication-factor 3 --partitions 4(testpro34)
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

–replication-factor 1 --partitions 4(testpro14)
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

5個(gè)分區(qū)（partitions）

–replication-factor 4 --partitions 5(testpro45)
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

–replication-factor 3 --partitions 5(testpro35)
1000000 條大小為 1KB 的消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

2個(gè)broker的集群

4個(gè)副本3個(gè)分區(qū)（test）與4個(gè)副本5個(gè)分區(qū)（testpro45）生產(chǎn)1000000條數(shù)據(jù)對(duì)比：
test吞吐量相對(duì)高一點(diǎn)點(diǎn)(高3 mb/sec)，而平均時(shí)延、最大時(shí)延、即生產(chǎn)各完成百分段時(shí)延都是testpro45較低

4個(gè)副本3個(gè)分區(qū)（test）與4個(gè)副本4個(gè)分區(qū)（testpro）生產(chǎn)1000000條數(shù)據(jù)對(duì)比：
testpro吞吐量高很多(高51 mb/sec)，而平均時(shí)延、最大時(shí)延、即生產(chǎn)各完成百分段時(shí)延都是testpro低

3個(gè)副本4個(gè)分區(qū)（testpro34）與4個(gè)副本4個(gè)分區(qū)（testpro）生產(chǎn)1000000條數(shù)據(jù)對(duì)比：
testpro吞吐量相對(duì)較高(高15 mb/sec)，而平均時(shí)延testpro34相對(duì)較低，最大時(shí)延testpro44相對(duì)較低，50%的消息時(shí)延testpro34較低，95%之后都是testpro的消息時(shí)延較低！

4個(gè)副本4個(gè)分區(qū)（testpro）與4個(gè)副本5個(gè)分區(qū)（testpro45）生產(chǎn)1000000條數(shù)據(jù)對(duì)比：
testpro吞吐量高很多(高54 mb/sec)，而平均時(shí)延、最大時(shí)延、即生產(chǎn)各完成百分段時(shí)延都是testpro低

在同等條件下，消息數(shù)為1000000，分區(qū)數(shù)由小到大變化，其他參數(shù)不變，4個(gè)分區(qū)時(shí)，性能最優(yōu)。

compression（壓縮算法）

kafka-consumer-perf-test.sh,kafka,kafka,分布式

在同等條件下，消息數(shù)為1000000，壓縮算法為gzip、snappy、lz4，其他參數(shù)不變，當(dāng)采用lz4時(shí)吞吐量最高，而對(duì)于消息時(shí)延來說，gzip的平均和最大時(shí)延都是最低。

建議只有在producer cpu資源充裕的情況下，才開啟壓縮，否則會(huì)使機(jī)器cpu資源耗盡，反而得不償失;
如果寬帶資源比較緊張，建議開啟壓縮，可以使用zstd，極大的減少網(wǎng)絡(luò)資源開銷

Consumer（消費(fèi)者）

compression（壓縮算法）

使用不同的壓縮算法生產(chǎn)消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

kafka-consumer-perf-test.sh,kafka,kafka,分布式

使用不同的解壓縮算法消費(fèi)消息
kafka-consumer-perf-test.sh,kafka,kafka,分布式

在同等條件下，消息數(shù)為1000000，壓縮算法為gzip、snappy、lz4，其他參數(shù)不變，當(dāng)生產(chǎn)和消費(fèi)消息時(shí)采用lz4時(shí)性能最優(yōu)。

threads（線程）

bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 8 compression.type=lz4
kafka-consumer-perf-test.sh,kafka,kafka,分布式

bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 4

kafka-consumer-perf-test.sh,kafka,kafka,分布式

threads 1
kafka-consumer-perf-test.sh,kafka,kafka,分布式

獲取消息的線程數(shù)與實(shí)際吞吐率影響不大。
在增加分區(qū)數(shù)與消費(fèi)線程數(shù)時(shí)，在小于3個(gè)分區(qū)時(shí)，3個(gè)分區(qū)與3個(gè)消費(fèi)線程性能最優(yōu)，在其他條件不改變的前提下，再進(jìn)一步增加分區(qū)數(shù)與消費(fèi)程數(shù)時(shí)，實(shí)際吞吐量變化不大。

配置建議

基于kafka的高度可配置的特性，可以應(yīng)用到不同的業(yè)務(wù)場(chǎng)景，比如，實(shí)時(shí)性較強(qiáng)的跟蹤用戶在頁(yè)面上的行為動(dòng)作、實(shí)時(shí)性不高但可靠性很高的信用卡支付操作的處理等。

可靠性配置：

replication.factor

副本因子，針對(duì)topic級(jí)別的配置參數(shù)是replication.factor，以本次測(cè)試為例，有3個(gè)broker實(shí)例，建議合理的復(fù)制系數(shù)為1-3，以3為例，也就是每個(gè)分區(qū)會(huì)被3個(gè)broker各復(fù)制一次，即每個(gè)broker保存一個(gè)分區(qū)，即使在2個(gè)broker失效的情況下，仍然可以向topic寫入消息或從topic讀取消息?？偨Y(jié)如下：
如果復(fù)制系數(shù)為N，那么在N-1個(gè)broker失效的情況下，仍然具備讀寫能力，因此更高的復(fù)制系數(shù)會(huì)帶來更高的可靠性，但另一方面，N個(gè)復(fù)制系數(shù)需要至少N個(gè)broker，而且會(huì)有N份數(shù)據(jù)副本(副本包含leader與follower)。

unclean.leader.election.enable

不完全的leader選舉，unclean.leader.election.enable在broker級(jí)別上進(jìn)行配置，默認(rèn)值為true(僅在當(dāng)前版本為true，后續(xù)高版本為false)確保分區(qū)可從非 ISR 中選舉 leader，官方在kafka高版本發(fā)行時(shí)，修改了這個(gè)默認(rèn)值，暫時(shí)理解為官網(wǎng)的推薦設(shè)置，但對(duì)于實(shí)時(shí)性較高的業(yè)務(wù)，比如實(shí)時(shí)統(tǒng)計(jì)用戶訪問量的分析，一般會(huì)啟用這個(gè)配置，即設(shè)置為true，但對(duì)于可靠性較高的業(yè)務(wù)，比如銀行的業(yè)務(wù)，寧可花費(fèi)幾分鐘或幾個(gè)小時(shí)的延時(shí)后再處理像信用卡支付的業(yè)務(wù)，也不會(huì)冒險(xiǎn)處理錯(cuò)誤的消息。因此，按真實(shí)的業(yè)務(wù)場(chǎng)景來設(shè)置即為合理。

min.insync.replicas

最少同步副本，min.insync.replicas默認(rèn)是1，本次測(cè)試中采用了3個(gè)broker，因此這個(gè)值可以設(shè)置1-3，當(dāng)然如果選擇3時(shí)，即為最少要同步3個(gè)副本才可以向分區(qū)寫入數(shù)據(jù)，即為真正的提交，需要注意的是如果有1個(gè)broker出現(xiàn)問題，無法同步副本，那么剩下的broker就會(huì)停止生產(chǎn)者的所有請(qǐng)求，并拋出NotEnouqhReplicasException給生產(chǎn)者，直至問題broker恢復(fù)，此時(shí)消費(fèi)者可以正常讀取消息。

producer

producer發(fā)送確認(rèn)，生產(chǎn)者可以選擇3種不同模式的確認(rèn)，acks為0時(shí)，只要生產(chǎn)者把消息發(fā)送出去，即認(rèn)為已成功寫入broker，這種模式下運(yùn)行速度非常快，吞吐率和帶寬利用率非常高，不過采用這種模式風(fēng)險(xiǎn)較高，容易丟失一些消息。一般壓力測(cè)試都是基于這個(gè)模式的。使用實(shí)時(shí)性較高的系統(tǒng)，也不建議采用該模式。

acks

acks為1時(shí)，即為leader收到消息并寫入分區(qū)數(shù)據(jù)文件(不一定同步到磁盤)后，提交成功，返回確認(rèn)響應(yīng)。
acks為-1或all時(shí)，即leader收到消息后，會(huì)等待所有同步副本都收到消息，才會(huì)返回確認(rèn)響應(yīng)。

acks = 0
如果設(shè)置為零，則生產(chǎn)者將不會(huì)等待來自服務(wù)器的任何確認(rèn)，該記錄將立即添加到套接字緩沖區(qū)并視為已發(fā)送。在這種情況下，無法保證服務(wù)器已收到記錄，并且重試配置將不會(huì)生效（因?yàn)榭蛻舳送ǔ２粫?huì)知道任何故障），為每條記錄返回的偏移量始終設(shè)置為-1。
acks = 1
這意味著leader會(huì)將記錄寫入其本地日志，但無需等待所有副本服務(wù)器的完全確認(rèn)即可做出回應(yīng)，在這種情況下，如果leader在確認(rèn)記錄后立即失敗，但在將數(shù)據(jù)復(fù)制到所有的副本服務(wù)器之前，則記錄將會(huì)丟失。
acks = all
這意味著leader將等待完整的同步副本集以確認(rèn)記錄，這保證了只要至少一個(gè)同步副本服務(wù)器仍然存活，記錄就不會(huì)丟失，這是最強(qiáng)有力的保證，這相當(dāng)于acks= -1的設(shè)置。
可以設(shè)置的值為：all, -1, 0, 1

producer

producer失敗重試參數(shù)，當(dāng)生產(chǎn)者沒有收到成功的響應(yīng)，重試發(fā)送次數(shù)，當(dāng)前版本默認(rèn)為0，根據(jù)實(shí)際業(yè)務(wù)來設(shè)置該參數(shù)，并非越大越好，也不建議設(shè)置為0，生產(chǎn)者收到的錯(cuò)誤會(huì)包括2種，一種是可恢復(fù)性錯(cuò)誤，一種是不可恢復(fù)性錯(cuò)誤，遇到可恢復(fù)性的錯(cuò)誤時(shí)，可以通過重試來解決，不可恢復(fù)性錯(cuò)誤，只能由開發(fā)者手動(dòng)處理。但由于網(wǎng)絡(luò)原因造成的無法收到成功響應(yīng)，此時(shí)如果無限次的重試發(fā)送，會(huì)造成分區(qū)內(nèi)存在重復(fù)消息，增加了消費(fèi)者讀取消息時(shí)的業(yè)務(wù)處理的復(fù)雜度。因此分析實(shí)際業(yè)務(wù)場(chǎng)景，謹(jǐn)慎設(shè)置。

consumer auto.offset.reset

consumer auto.offset.reset，默認(rèn)值為latest,即在沒有offset時(shí)，消費(fèi)者會(huì)從分區(qū)的末尾開始讀取數(shù)據(jù)，減少讀取重復(fù)消息的可能性，但可能會(huì)錯(cuò)過一些消息。設(shè)置為earliest，當(dāng)出現(xiàn)offset不存在的情況時(shí)，從分區(qū)的開始位置讀取數(shù)據(jù)，這樣會(huì)讀取大量重復(fù)消息，由消費(fèi)端的業(yè)務(wù)邏輯來處理重復(fù)消息。增加了業(yè)務(wù)的復(fù)雜度。

當(dāng)kafka中沒有初始o(jì)ffset或offset超出范圍時(shí)將自動(dòng)重置offset
earliest:重置為分區(qū)中最小的offset;
latest:重置為分區(qū)中最新的offset(消費(fèi)分區(qū)中新產(chǎn)生的數(shù)據(jù));
none:只要有一個(gè)分區(qū)不存在已提交的offset,就拋出異常;

consumer auto.commit.interval.ms

consumer auto.commit.interval.ms，默認(rèn)值為5000ms，即5秒提交一次，可以通過該參數(shù)來設(shè)置提交的頻度，一般來說，提交頻度越高，越會(huì)帶來更高的系統(tǒng)開銷，可靠性也隨之提高。

1、實(shí)時(shí)類業(yè)務(wù)

實(shí)時(shí)類業(yè)務(wù)，把零延時(shí)作為第一考慮因素，比如聊天室、會(huì)議室、直播類似系統(tǒng)等，在保證最小延時(shí)的基礎(chǔ)上，適當(dāng)設(shè)置可靠性相關(guān)參數(shù)。建議可靠性參數(shù)如下：

replication.factor:1

unclean.leader.election.enable:true

min.insync.replicas:1

acks:0

retries:0

2、近實(shí)時(shí)類業(yè)務(wù)

即可接受一定范圍內(nèi)的延時(shí)，比如實(shí)時(shí)計(jì)算用戶訪問量等類似web監(jiān)控類業(yè)務(wù)，在保證最小延時(shí)的基礎(chǔ)上，適當(dāng)設(shè)置可靠性相關(guān)參數(shù)。建議可靠性參數(shù)如下：

replication.factor:2

unclean.leader.election.enable:true

min.insync.replicas:2

acks:1

retries:1/2/3

consumer auto.commit.interval.ms:1000ms

consumer auto.offset.reset:latest

3、非實(shí)時(shí)類業(yè)務(wù)

非實(shí)時(shí)類業(yè)務(wù)，即可以允許一定時(shí)間的延時(shí)，從而來保證系統(tǒng)更高的可靠性。以3個(gè)broker以例，建議可靠性參數(shù)如下：

replication.factor:3 

unclean.leader.election.enable:false

min.insync.replicas:2/3

acks:all

retries:MAX_INT

consumer auto.commit.interval.ms:500ms

consumer auto.offset.reset:earliest

kafka-consumer-perf-test.sh,kafka,kafka,分布式文章來源地址http://www.zghlxwxcb.cn/news/detail-763555.html

到了這里，關(guān)于【kafka性能測(cè)試腳本詳解、性能測(cè)試、性能分析與性能調(diào)優(yōu)】的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！

国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

Toy模板網(wǎng)

【kafka性能測(cè)試腳本詳解、性能測(cè)試、性能分析與性能調(diào)優(yōu)】