Metric publish 查核點討論

[chinghongfang]

Mertric publish (#1281) 這項新功能為產學驗收項目，在此開立議題討論與訂定。

查核環境

6 brokers, 1000 topics 每個 topic 各 90 partitions， 抽樣速率 1 秒一次，9 台 clients。
實驗使用的 client 將會使用 astraea performance tool 進行驗證。Cost-function 都將使用 broker 端 partition level 的效能指標 (LogMetrics.Log.SIZE) 也就是使用 cost-function (NetworkCost) 來執行。
Producer partitioner 的部份會使用 astraea 專案內的 Dispatcher, StrictCostDispatcher。
Consumer assignor 的部份會使用 astraea 專案內的 Assignor, CostAwareAssignor。

實驗執行：

將會觀測 Producer 的效能 和 Consumer rebalance 時的資源消耗。
Producer 限流發送 record 到 1000 topics 上，這些 topic-partition 的分佈不一定是均勻分佈。
Consumer 同時對 1000 topic 消費，期間 consumer 會觸發 rebalance。

同時將會觀測 Balancer 的資源消耗。
上面會對 Producer 限流是因為要保留空間給 Balancer 搬移 partition。
Consumer 同時對 1000 topic 消費。
啟動 Balancer 進行搬移計畫計算，搬移計畫計算包括 metric 拉取。

硬體規格

broker 和 client 如 #130 所述的 (01~09, 15~20號伺服器)

比較對象

clients 各自建立 jmx 連線（現行作法）

查核點

• producer 使用 StrictCostPartitioner 時，資源消耗減少 20%，且吞吐量不降低
• consumer 使用 CostAwareAssignor 時， rebalance 資源消耗減少 20%，且吞吐量不降低
• balancer 計算計畫時，資源消耗減少 20%，且產生的計畫數量不降低超過 5%

[chia7712]

感謝更新，幾個建議：

1. 可否說明有幾個實體機作為伺服器端和客戶端
2. 監控用的軟體可以放在rack外，應該不會有效能問題
3. 請把不同項目的文字用大標題區隔開來，例如查核環境是一個區塊、節點規格是一個區塊
4. Topic的數量至少要1000個，這樣比較真實
5. 查核點前面兩個理論上應該就是同時發生，所以當作兩個查核點會怪怪的
6. 請問第四點的暖機是什麼意思？

[chinghongfang]

謝謝 @chia7712 提供的建議，議題內容已更新再麻煩您過目。

2. 監控用的軟體可以放在rack外，應該不會有效能問題

我現在也認為沒問題，不過因為我們比較的對象沒有所謂 "監控用的軟體"，所以我沒有特別寫 "監控用的軟體"，請問有需要在環境裡面說 "監控用的軟體" 在不同的 rack 上嘛？

4. Topic的數量至少要1000個，這樣比較真實

好的，不過這樣就肯定沒辦法蒐集所有有紀錄的 jmx metrics （改良前後都難以做到），要從中挑出有價值、有需要的 metric 來蒐集。

6. 請問第四點的暖機是什麼意思？

這個其實是想要表達，提供新功能可以拉取歷史數據，但因為各項查核點皆需要量化，所以拿 "應用端可能需要暖機時間" 這件事來當作指標，請問是否有更好的寫法？或是把這一點拿掉？

[chia7712]

我現在也認為沒問題，不過因為我們比較的對象沒有所謂 "監控用的軟體"，所以我沒有特別寫 "監控用的軟體"，請問有需要在環境裡面說 "監控用的軟體" 在不同的 rack 上嘛？

主要是我希望你這邊也能用滿15個節點，所以如果有要用監控或一些配合的軟體就移動到其他rack上的節點

好的，不過這樣就肯定沒辦法蒐集所有有紀錄的 jmx metrics （改良前後都難以做到），要從中挑出有價值、有需要的 metric 來蒐集。

我會建議搭配 assignor or dispatcher or balancer 的一個情境，因此就以該情境所需的metrics 收集作為比較對象就好

這個其實是想要表達，提供新功能可以拉取歷史數據，但因為各項查核點皆需要量化，所以拿 "應用端可能需要暖機時間" 這件事來當作指標，請問是否有更好的寫法？或是把這一點拿掉？

我建議要去彰顯「拉取歷史資料的好處」，例如我們可以用一個吞吐量很不固定的情景，當沒有歷史資料時會做出不適合的成本估計導致xxx後果，然後有了歷史資料可以做出比較準的成本估計得到yyy結果，而yyy結果可以比xxx結果改善多少%

[chinghongfang]

主要是我希望你這邊也能用滿15個節點，所以如果有要用監控或一些配合的軟體就移動到其他rack上的節點

好的，已更新到 issue 內容。

我會建議搭配 assignor or dispatcher or balancer 的一個情境，因此就以該情境所需的metrics 收集作為比較對象就好

了解。
那我應該會搭配 "dispatcher 的一個情境" 或 "assignor 的一個情境"，因為這個實驗需要較多的 client 比較容易有較顯著的成果，又如果混合著用(dispatcher, assignor and balancer)的話，情境可能會變得有些複雜。

我建議要去彰顯「拉取歷史資料的好處」，例如我們可以用一個吞吐量很不固定的情景，當沒有歷史資料時會做出不適合的成本估計導致xxx後果，然後有了歷史資料可以做出比較準的成本估計得到yyy結果，而yyy結果可以比xxx結果改善多少%

"比較準" 是自己定義嗎？比如說，類似 最小平方法 用 (預測值-實際值)^2 來當作準確度嗎？不過 Cost function 都會把數據轉換成一個分數，但我們不會有 "實際分數" 這種數值，而且每個 Cost 轉換的方法也不一樣，這樣有辦法定義 "比較準" 嗎？

[chia7712]

"比較準" 是自己定義嗎？比如說，類似 最小平方法 用 (預測值-實際值)^2 來當作準確度嗎？不過 Cost function 都會把數據轉換成一個分數，但我們不會有 "實際分數" 這種數值，而且每個 Cost 轉換的方法也不一樣，這樣有辦法定義 "比較準" 嗎？

這邊的「比較準」要從 cost function的結果來定義，例如我們在一個吞吐量不固定的環境中，用原本抓metrics的計算方式可能會得到不准的吞吐量導致最後 dispatcher 的吞吐量只有 xx，然後用你的metrics 功能可以得到很準確的結果進而提升吞吐量到yy ，而這個XX和yy 的差距就是「比較準」後的結果

[chinghongfang]

用你的metrics 功能可以得到很準確的結果進而提升吞吐量到yy ，而這個XX和yy 的差距就是「比較準」後的結果

了解。以稍微修改第三點。
另外，"吞吐量不固定的環境" 我想這個情境還是需要有週期性的變化，不然有再多的歷史資料都不夠。週期性的變化目前工具應該還無法製造，需要再往 performance tool 新增功能。
請問有需要明確寫 "使用的 Cost function" 和 "吞吐量不固定的環境" 是 "如何的" 不固定嗎？

[chia7712]

請問有需要明確寫 "使用的 Cost function" 和 "吞吐量不固定的環境" 是 "如何的" 不固定嗎？

我上面說的是一個「舉例」，不一定要做這個情境，可以思考一下

[chinghongfang]

更新查核點內容。改成用 dispatcher, assignor, balancer 的效能提昇、資源減少來作為查核點。細節代訂。

[chia7712]

@chinghongfang 文字的部分要先寫上去喔，提升的數字可以晚點補

[chinghongfang]

@chinghongfang 文字的部分要先寫上去喔，提升的數字可以晚點補

有更新大致目標了（提升producer, consumer, 降balancer資源），細節（環境、cost function、比什麼）還要跑實驗來確認，請問這 “文字的部分” 還缺些什麼？

[chia7712]

請問這 “文字的部分” 還缺些什麼？

要用完整的文字描述驗收項目，現在寫的太簡略。例如 producer 效能提升，應該要寫說在搭配 astaraea dispatcher時，可以在降低 metrics的拉取成本下，維持相同/更好的寫入表現

[chinghongfang]

這裡先更新實驗的狀況。
把 #1369 的功能串到 Dispatcher 上使用，測試了幾個情境（調整 producer 數量、給 producer 限流）都不容易在 Dispatcher 上看到效果。（目前是使用 StrictCostDispatcher 並使用 cost function BrokerInputCost 來測試）

推測主要因為是 BrokerInputCost 所需 "拉取的 metric 量少"，優化空間不大，難以看出區別。BrokerInputCost 每個 broker 只會有一個 mbean 需要索取。

現在將嘗試使用 partition level 的 metric 當作效能指標，看看能否有較大的優化。

[chia7712]

現在將嘗試使用 partition level 的 metric 當作效能指標，看看能否有較大的優化。

是的，要用這個方式，並且將 partitions 的數量開大一點

[chinghongfang]

已經更新 issue 內容，對實驗環境有更多描述，再請 @chia7712 過目。

另外，consumer, balancer 因為比較不熟悉、也不確定兩者是否會不斷做 metric 收集，所以寫得較為保守，而且把 "觀測點" 寫得比較細節，比如說 "rebalance 時"、"計算計畫時"。
如果可以確定 consumer, balancer 會一直拉取 metric，那我覺得可以把這兩個 "觀測點" 拿掉。

[chia7712]

另外，consumer, balancer 因為比較不熟悉、也不確定兩者是否會不斷做 metric 收集，所以寫得較為保守，而且把 "觀測點" 寫得比較細節，比如說 "rebalance 時"、"計算計畫時"。
如果可以確定 consumer, balancer 會一直拉取 metric，那我覺得可以把這兩個 "觀測點" 拿掉。

我建議 producer 端也改成資源消耗減少，這樣可以用同樣手法去觀察這三種應用

[chinghongfang]

已經更新查核點項目 (此issue 第一個留言)，以下為更新項目：

更新 broker, client 數量變成 6台, 9台。
降低 partition 數量保持每台 broker 大約持有 15000 partition。
更改實驗執行，改成 partitioner, assignor, balancer 同時進行。
增加查核點限制，確保資源用量的減少 不是 用效能換來的。