Performance tool 吞吐量問題

[chinghongfang]

• Astraea 版本：0e555a52acef8111aa732f7629c44cd7c1380330
• 3 broker, 3 performance tool
• 1 topic: 30 partition 1 replica
• 使用預設 partition 分佈

在 3 台伺服器做 broker，另外 3 台伺服器同時啟動 performance tool 執行以下指令時，每個 broker 的網路吞吐量約在 3 Gb/sec，topic 大小的增加速率約為 970 MiB/sec。

astraea/docker/start_app.sh performance \
--bootstrap.servers 192.168.103.185:9092,192.168.103.186:9092,192.168.103.187:9092 \
--producers 4 \
--consumers 10 \
--value.size 10KiB \
--topics testing \
--run.until 30m

但是 3 台 performance tool、 3 台 broker 兩邊各有 30 Gb/sec 的頻寬，不應該只有 10 Gb/sec 的吞吐量才對。配置不變，改使用其他較舊版本 astraea 再測試，便有以下比較圖。

# 舊版本的測試指令
REVISION=3133d89960ef01c9eb4404d40a529de21526fa60 \
astraea/docker/start_app.sh performance \
--bootstrap.servers 192.168.103.185:9092,192.168.103.186:9092,192.168.103.187:9092 \
--producers 4 --consumers 10 \
--value.size 10KiB \
--topic testing \
--run.until 30m  \
--partitions 30

(左邊完整區塊是專案的最新版本，中間零散的突起是跑短暫的performance tool，右邊完整區塊是使用專案的 revision 3133d89 來跑 performance tool)

---

使用相同的配置，但不同的版本，故推測問題出在 performance tool 。

[chia7712]

@chinghongfang 感謝回報，如果短時間內看不出所以然，可以逐一 commit 測試，然後看是哪一隻 commit 造成這個 regression

[chia7712]

@chinghongfang any update? We should fix performance regression before 0.1.0 release.

[chinghongfang]

We should fix performance regression before 0.1.0 release.

好的，我會盡快尋找問題點。

[chinghongfang]

尚未找到問題點，但這邊先提供線索看看有沒有人有頭緒。

反覆測試以後，發現問題 (吞吐量低) 從 #571 開始出現，該 PR 主要修改 consumer builder seek offset 的部分。

另外發現在 #571 這隻PR 上

• 把 consumer 數量調成 0 or 1 後，傳輸量就正常了
• 把 consumer 數量調成 6 後，傳輸量降低，但沒有 consumer 數量 10 降低得多

#571 改的內容幾乎都是 consumer thread 初始化的東西，和運行時的效能應該關係不大？且從後來調整 consumer 數量的發現，看起來是跟 consumer 數量有關的問題。

[chia7712]

把 consumer 數量調成 6 後，傳輸量降低，但沒有 consumer 數量 10 降低得多

直覺是頻寬爭奪？有試過跑最新的code然後把consumer設定成0嗎

[chinghongfang]

有試過跑最新的code然後把consumer設定成0嗎

新的也是，把 consumer 數量設定成 0 就正常了

[chia7712]

新的也是，把 consumer 數量設定成 0 就正常了

那..應該就是頻寬被分走而已吧?

[chinghongfang]

後來發現，過去的 commit 有比較高的吞吐量是因為 consumer 沒有建立完，且沒有開始消費，如此便相當於 0 個 consumer 的狀況。
過去的 commit 無法建立完 consumer ，原因是在 comment 提到， consumer 要先 poll 才可以做 offset seek，所以 consumer 的建立會卡住。

所以其實現在的版本應該才是正常的。

[chia7712]

@chinghongfang 感謝追蹤和分享。可否試著總結以下幾個問題：

1. 在沒有consumers 的狀態下，新舊版本的 producer 速度是否有差異？
2. 有啟動 consumers 的狀態下，consumers 數量和寫入速度的互相影響是否主要為頻寬的爭奪？

[chinghongfang]

在沒有consumers 的狀態下，新舊版本的 producer 速度是否有差異？

肉眼觀察沒有差異。

有啟動 consumers 的狀態下，consumers 數量和寫入速度的互相影響是否主要為頻寬的爭奪？

這裡說的 "頻寬" 是指網路頻寬吧？我們的網路都是全雙工的，上傳、下載的頻寬應該不互相影響吧？還是說這裡指的 "頻寬爭奪" 不是在講網路的頻寬？

---

另外發現，前面的實驗情境是 3 台伺服器同時啟動 performance tool 打同一個 topic，所以會有 3 個 consumer group 消費同一個 topic，這樣產生的是 "讀取較重" 的環境。所以我後來又跑了一次 3 台伺服器同一個 consumer group，

# 三台伺服器都跑以下指令
docker/start_app.sh performance \
--bootstrap.servers 192.168.103.185:9092,192.168.103.186:9092,192.168.103.187:9092 \
--producers 4 \
--consumers 10 \
--value.size 10KiB \
--topics testing \
--run.until 30m \
--group.id groupA

讓寫入、讀取比重相同，而 producers 的吞吐量也提昇了。

下圖是 其中一台 broker 的網路流量監控圖表，而 3 台 broker 的網路流量圖表類似，所以這邊選其中一台放上， x 軸是時間，y 軸正向是下載量 (produce to broker)，y 軸負向是上傳量 (consume from broker)

圖片解釋：
最左側是只有 producer
中間是 3 台伺服器的 performance tool 有各自的 consumer group
最右側是 3 台伺服器的 performance tool 在同一個 consumer group

最左邊只執行 producer 是我認為應該要有的正常表現；中間的下載量 (produce to broker) 明顯低落，但上傳量(consume from broker) 是很接近網路頻寬上限的；右邊的下載量 (produce to broker) 雖然不如 最左邊 的表現，但我理解為因為 client 端還有 consumer thread 要處理，無法和全部做 produce 相提並論。

以上額外的資訊再提供您做參考。

[chia7712]

這裡說的 "頻寬" 是指網路頻寬吧？我們的網路都是全雙工的，上傳、下載的頻寬應該不互相影響吧？還是說這裡指的 "頻寬爭奪" 不是在講網路的頻寬？

producer/consumer 都會有上傳下載的動作，不過我主要是問現在perf tool 會否因為開了 consumer 就出現明顯的效能影響

中間是 3 台伺服器的 performance tool 有各自的 consumer group
最右側是 3 台伺服器的 performance tool 在同一個 consumer group

這個比法怪怪的，因為前者的資料讀取量會是後者的三倍（例如都是produce 1 byte，前者要撈三次回來、後者只需要撈一次），因此效能圖比較像是 broker 的資源被 consume requests們佔據了

總之，現在看起來似乎沒有出現明顯的 performance regression?

[chinghongfang]

這個比法怪怪的，因為前者的資料讀取量會是後者的三倍（例如都是produce 1 byte，前者要撈三次回來、後者只需要撈一次），因此效能圖比較像是 broker 的資源被 consume requests們佔據了

是的，我也認為應該是資源被 consume requests 佔據了，所以才另外做了一個 1 consumer group 的實驗， 1 個 consumer group 的 producer 吞吐也變比較正常了。

總之，現在看起來似乎沒有出現明顯的 performance regression?

是的，我也這麼認為。

[chia7712]

是的，我也這麼認為。

那就麻煩關閉此議題 :)