Replica#hashcode 執行代價變高

[garyparrot]

Related PR: #1763, #1782

https://github.com/skiptests/astraea/blob/ced840f9ded6e4167ccbbc86a20f79f7ec6be0c0/common/src/main/java/org/astraea/common/admin/Broker.java#L36-L44

由於 Broker 本身儲存的狀態涉及 topic/partition，這連帶讓和他有關的物件的 hashcode 計算量和叢集大小線性相關，有一些和他有關的物件的 hashcode 速度有變慢的現象，如 Replica。下面是在有 10000+ partition 的叢集做的測試：

  @Test
  @Disabled
  void test() {
    try (Admin admin = Admin.of(realCluster)) {
      // 取得 cluster info
      ClusterInfo clusterInfo = admin.topicNames(false).thenCompose(admin::clusterInfo).toCompletableFuture().join();
      // output: 10140
      System.out.println("Replicas Count: " + clusterInfo.replicas().size());

      var summary = new LongSummaryStatistics();

      // 執行每個 replica 的 hashcode
      clusterInfo.replicas().forEach(r -> {
        long s = System.nanoTime();
        if(clusterInfo.replicas().get(0).hashCode() == 0) System.out.println("");
        long t = System.nanoTime();
        summary.accept(t - s);
      });

      // 輸出平均執行時間
      System.out.println(Duration.ofNanos((long) summary.getAverage()).toNanos());
    }
  }

使用 Broker 前 (28ec2c6

Replicas Count: 10104
1758

使用 Broker 後 (ced840f

Replicas Count: 10104
81787

這個速度的影響對 Map 把 Replica 或 Broker 當 key 使用時比較有感。

[chia7712]

@garyparrot 感謝回報，可否指出幾個例子我們需要使用Broker hash code的地方？

[garyparrot]

https://github.com/skiptests/astraea/blob/ced840f9ded6e4167ccbbc86a20f79f7ec6be0c0/common/src/main/java/org/astraea/common/balancer/BalancerUtils.java#L134

https://github.com/skiptests/astraea/blob/6b4e546d6040599737d5e68942900aba5656e52c/common/src/main/java/org/astraea/common/balancer/algorithms/GreedyBalancer.java#L182

https://github.com/skiptests/astraea/blob/6b4e546d6040599737d5e68942900aba5656e52c/common/src/main/java/org/astraea/common/balancer/algorithms/SingleStepBalancer.java#L112

https://github.com/skiptests/astraea/blob/124a096884aec5732e0f0330f69becaae5da9d4e/common/src/main/java/org/astraea/common/balancer/tweakers/ShuffleTweaker.java#L102

https://github.com/skiptests/astraea/blob/ced840f9ded6e4167ccbbc86a20f79f7ec6be0c0/common/src/main/java/org/astraea/common/cost/BrokerDiskSpaceCost.java#L86

https://github.com/skiptests/astraea/blob/ced840f9ded6e4167ccbbc86a20f79f7ec6be0c0/common/src/main/java/org/astraea/common/cost/BrokerDiskSpaceCost.java#L117

https://github.com/skiptests/astraea/blob/ced840f9ded6e4167ccbbc86a20f79f7ec6be0c0/common/src/main/java/org/astraea/common/cost/MigrationCost.java#L102

剛剛看了一下專案內會間接呼叫到 Broker#hashcode 或 Broker#equals (equals 也會觸碰到昂貴的比較) 的是上面這幾個部分。

這個速度的影響對 Map 把 Replica 或 Broker 當 key 使用時比較有感。

原文提到的這個部分是我自己測試用的程式碼，所以或許和專案比較無關，這兩個函數的呼叫看起來目前還是比較罕見的

[chia7712]

@garyparrot 感謝整理，那我接手處理這個議題

[chia7712]

System.out.println(Duration.ofNanos((long) summary.getAverage()).toNanos());

我剛剛才注意到時間單位是奈秒 ... 這樣的話傷害應該不大，還是 @garyparrot 你有其他考量？

[garyparrot]

我剛剛才注意到時間單位是奈秒 ... 這樣的話傷害應該不大，還是 @garyparrot 你有其他考量？

抱歉，我剛剛測試了一下我自己 repo 那邊的影響不大 (10000 partition)，後來有確定執行速度緩慢是其他部分的程式碼造成的。

[chia7712]

抱歉，我剛剛測試了一下我自己 repo 那邊的影響不大 (10000 partition)，後來有確定執行速度緩慢是其他部分的程式碼造成的。

感謝回覆，沒關係，這也讓我注意到一些資料結構的問題

[chia7712]

#1792 and #1791 應該有減緩這個問題了，所以關閉議題