增量同步處理效能白皮書

測試環境

• Table Store執行個體

  • 執行個體類型：高效能執行個體

  • 執行個體地區：華東1（杭州）

  • 執行個體地址：私網地址，避免網路的不確定性因素對測試造成的幹擾

• 測試機器配置

  • 類型：阿里雲ECS

  • 地區：華東1（杭州）

  • 型號：共用通用型(mn4) ecs.mn4.4xlarge

  • 配置：

    • CPU：16核

    • 記憶體：64 GB

    • 網卡：Red Hat、Inc Virtio network device

    • 作業系統：CentOS 7u2

測試載入器

• 壓力器

  壓力器使用Table Store內部使用的壓力測試工具進行資料的批量並發寫入，底層基於Table StoreJava SDK的BatchWrite操作完成。

• 預分區工具

  使用Table Store內部使用的壓力測試工具，配置好表名和分區數等資訊，進行表格的自動建立和預分區。

• 速率統計器

  增量的即時消費速率統計基於Tunnel Java SDK完成，在傳入的Callback中加入下圖中類似的速率統計邏輯，進行速率和消費總行數的即時統計。

  樣本

  private static final Gson GSON = new Gson();
  private static final int CAL_INTERVAL_MILLIS = 5000;
  
  static class PerfProcessor implements IChannelProcessor {
      private static final AtomicLong counter = new AtomicLong(0);
      private static final AtomicLong latestTs = new AtomicLong(0);
      private static final AtomicLong allCount = new AtomicLong(0);
  
      @Override
      public void process(ProcessRecordsInput input) {
          counter.addAndGet(input.getRecords().size());
          allCount.addAndGet(input.getRecords().size());
          if (System.currentTimeMillis() - latestTs.get() > CAL_INTERVAL_MILLIS) {
              synchronized (PerfProcessor.class) {
                  if (System.currentTimeMillis() - latestTs.get() > CAL_INTERVAL_MILLIS) {
                      long seconds = TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis() - latestTs.get());
                      PerfElement element = new PerfElement(System.currentTimeMillis(), counter.get() / seconds, allCount.get());
                      System.out.println(GSON.toJson(element));
                      counter.set(0);
                      latestTs.set(System.currentTimeMillis());
                  }
              }
          }
      }
  
      @Override
      public void shutdown() {
          System.out.println("Mock shutdown");
      }
  }

測試方案

使用Tunnel進行資料同步時，在單Channel間是串列同步（串列是為了保障使用者資料的有序性），不同Channel間是相互並行的。在增量情境下，Channel數和表的分區數是相等的。由於Tunnel的整體效能和表的分區數有很大的關聯性，所以在本次的效能測試中，將主要考慮不同分區數（Channel數）對於Tunnel增量的同步速率的影響。

• 測試情境

  我們將主要測試以下情境。

  • 單機同步單分區

  • 單機同步4個分區

  • 單機同步8個分區

  • 單機同步32分區

  • 單機同步64分區

  • 2台機器同步64分區

  • 2台機器同步128分區

  說明

  上述測試情境不是產品能力的極限測試，對錶格儲存服務端的整體壓力較小。

• 測試步驟

  1. 建立資料表並進行預分區（不同分區數的測試都會有單獨的一張表）。

  2. 建立增量通道。

  3. 使用壓力器進行增量資料的寫入。

  4. 使用速率統計器進行QPS的即時統計，同時觀察程式佔用的系統資源（CPU、記憶體等）。

  5. 通過監控獲得增量資料同步消耗的總網路頻寬。

• 測試資料說明

  如下圖所示，範例資料由4個主鍵和1~2個屬性列組成，單行的大小在220位元組左右。第一主鍵（分區鍵）會使用4-Byte-Hash的方式產生，這樣可以確保壓測資料比較均勻的寫入到每個分區上。

  

測試單位

本次測試主要包含以下幾項指標。

• QPS（row）：每秒同步的資料行數。

• Avg Latency（ms/1000行）：同步1000行資料所需的時間，單位為毫秒。

• CPU（核）：資料同步消耗的單核CPU總數。

• Mem（GB）：資料同步消耗的物理總記憶體。

• 頻寬（MBps）：資料同步消耗的總網路頻寬。

測試結果

該部分主要概述各個情境下的指標測試結果，測試的細節可以參見測試細則部分。

• QPS和延遲

  下圖展示的是各個情境下每秒同步的資料行數和同步1000行資料所需的時間。從圖中我們看出QPS的增長和分區數的增加呈線性關係。

  在本次測試中，單機同步64分區情境下，將千兆的網卡成功打爆（參見測試細則部分），導致只有57萬的QPS。兩台機器對64分區進行同步後，平均QPS成功達到了78萬行左右，約等於單機-32分區情境下（42萬）的兩倍速率。而在最後的兩台機器-128分區情境下，Tunnel增量同步處理的QPS也成功達到了100萬行。

  

• 系統資源消耗

  下圖展示的是各個情境下CPU和記憶體的消耗情況，CPU基本上和分區數呈線性關係。

  在單機-單分區情境下，消耗的CPU為0.25個單核CPU。2台機器-128個分區的情境下，當同步QPS達到100萬行時，消耗的CPU也僅為10.2個單核CPU。從記憶體消耗方面看。在分區數較少時，CPU和分區數呈線性關係，而在分區數增加較多（32個和64個）時，單機記憶體消耗基本維持在5.3 GB左右。

  

• 網路總頻寬消耗

  下圖展示的是增量同步處理消耗的總頻寬，從圖中我們可以看出頻寬和Channel數的線性關係（略單機-16分區情境）。

  在單機-64分區情境下，我們可以看到頻寬總消耗為125 MBps，已經成功把千兆網卡打爆，而在換成2台機器-64分區進行資料消費後，我們發現64分區真正的輸送量為169 MBps，和單機-32分區的86 MBps的兩倍近乎相等。而在兩台機器-128分區的100萬QPS情境中，總輸送量也達到了220 MBps。

  

測試細則

• 單機單Channel：1.9萬QPS

  • 測試時間：2019/1/30 17:40

  • QPS：穩定速率19000行/秒左右；峰值速率：21800行

  • Latency：50ms/1000行左右

  • CPU佔用：單核25%左右

  • 記憶體佔用：總實體記憶體0.4%左右，即0.256 GB左右（測試機器記憶體為64 GB）

  • 網路頻寬消耗：4000 KB/s左右

• 單機4分區：7萬QPS

  

  • 測試時間：2019/1/30 20:00

  • QPS：穩定速率70000行/秒左右，峰值速度72400行/秒

  • Latency：14.28ms/1000行左右

  • CPU佔用：單核70%左右

  • 記憶體佔用：實體記憶體1.9%左右，即1.1 GB左右。（測試機器記憶體為64 GB）

  • 網路頻寬消耗：13 MBps左右

• 單機8分區：13萬QPS

  

  • 測試時間：2019/1/30 20:20

  • QPS：穩定速率130000行/秒，峰值速率141644行/秒

  • Latency：7.69ms/1000行左右

  • CPU佔用：單核120%左右

  • 記憶體佔用：物理總記憶體4.1%左右，即2.62 GB左右（測試機器記憶體為64 GB）

  • 消耗網路頻寬：27 MBps左右

• 單機32分區：42萬QPS

  

  • 測試時間：2019/1/31 15:50

  • QPS：穩定速率42萬行/秒，峰值速率447600行/秒

  • Latency：2.38ms/1000行

  • CPU佔用：單核450%左右

  • 記憶體佔用：8.2%左右，即5.25 GB左右（實體記憶體64 GB）

  • 增量資料消耗網路頻寬：86 MBps左右

• 單機64分區（千兆網卡被打滿）：57萬QPS

  

  • 測試時間：2019/1/31 22:10

  • QPS：穩定速率57萬行/秒左右，峰值速率581400行/秒

  • Latency：1.75ms/1000行左右

  • CPU佔用：單核640%左右

  • 記憶體佔用：8.4%左右，即5.376 GB左右

  • 增量資料消耗網路頻寬：125 MBps左右（達到千兆網卡的速率極限）

• 2台機器共同消費64分區：78萬QPS

  

  • 測試時間：2018/1/31 22:30

  • QPS：每台穩定速率在39萬行/秒左右，總的穩定速率在78萬行/秒左右

  • Latency：1.28ms/1000行

  • CPU佔用：每台單核420%左右，共單核840%

  • 記憶體佔用：每台8.2%左右，共16.4%（10.5 GB）

  • 增量資料消耗總網路頻寬：169 MBps左右（和單機64分區對比，可以看出單機的網路已經成為瓶頸）

• 2台機器共同消費128分區（兩台千兆機器的網卡近乎被打滿）：100萬QPS

  

  • 測試時間：2018/1/31 23:20

  • QPS：每台穩定速率在50萬行/秒左右，總的穩定速率在100萬行/秒左右

  • Latency：1ms/1000行左右

  • CPU佔用：每台單核560%左右，兩台共計單核1020%

  • 記憶體佔用：每台8.2%左右，共16.4%（10.5 GB）

  • 增量資料消耗總網路頻寬：220 MBps左右

總結

通過這次對於增量效能的實際測試，我們發現了單分區（或分區數較少）的速率主要取決於伺服器端的讀盤等延遲，本身機器資源的消耗很小。而隨著分區數增長，Tunnel增量的整體吞吐也進行了線性增長直至達到系統的瓶頸（本文中是網路頻寬）。最後，在單機資源被打滿的情況下，我們也可以通過添加新的機器資源進一步的提升系統整體的輸送量，有效驗證了Tunnel具備良好的水平擴充性。