Besu 區塊鏈 TPS 壓力測試

本文由 BSOS 技術團隊撰寫，揭示如何在 GCP/Azure 混合雲中，以 IBFT 共識進行高併發測試，提升企業區塊鏈效能極限。

。環境條件：混合雲（GCP/Azure） 。區塊鏈版本：Besu v. 25.7.0 。共識機制：IBFT 2.0 。出塊時間測項：3 秒 / 5 秒 。節點數：5 (全數 validator) 。共識機制：IBFT 2.0 。測試工具：Locust (https://locust.io/) 。交易種類：transfer()，每筆固定消耗 21,000 gas 。節點機器規格：

測試說明

工具

• Locust Locust (https://locust.io/) 是一套開源的負載測試工具（Load Testing Tool），使用 Python 編寫，專門用來模擬大量用戶並發請求，測試 Web 應用、API 或其他系統的效能和承載能力。
• Python 編寫測試主程式
• 方法 — 如下方表格，分別測試 3 秒以及 5 秒的出塊時間設置下，不同 gasLimit 的 TPS 結果。 — 實際建立 1,200 個有餘額的地址，以 Locust 驅動執行壓力測試。 — Locust 執行的交易內容為固定的 transfer() 耗用 gas 為 21,000。 — 同時，也觀察區塊是否已達到 transaction 處理數量的臨界點，即雖未達 gasLimit，但區塊打包的 transaction 已經到瓶頸。

測試設置補充

1. Locust 相關設置

• 實測 Besu RPC 的吞吐能力受限硬體 I/O，單一 RPC 節點只能承受 230 RPS (request per second)，因此必須以 Docker 容器建置 2 個 Locust 分別對不同 RPC 節點做發送，不同 RPC 節點所收到的 transactions 會做廣播同步。
• 對本測試來說，送出的 Request 數量每秒可達 400 RPS (request per second) 以上。

version: "3.8"
services:
  locust:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: locust-besu
    ports:
      - "8089:8089"
    environment:
      - LOCUST_HOST=http://35.201.231.223:8545
    volumes:
      - ./01-senders_part1_0_599.json:/locust/01-original-senders.json
  locust2:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: locust-besu-2
    ports:
      - "8079:8089"
    environment:
      - LOCUST_HOST=http://34.81.154.77:8545
    volumes:
      - ./01-senders_part2_600_up.json:/locust/01-original-senders.json

• 主程式 (locustfile.py)，採非同步（async）發送，避免阻塞與序列化造成效能低落。

2. Besu 相關設置

• Besu 創世檔 genesis.json 必須配合配置下列設定 — "maxtransactions": 2048 因為高併發場景，必須依賴交易池做緩衝，如果 RPC 節點交易池太小，超出交易池的交易會被丟棄。 — 根據上述表格，每次測試使用不同的gasLimit (16進制表示法) 例如： 3,000萬 gasLimit, 0x1fca055 依此類推。
• 接收 Locust 發送交易請求的 RPC 節點必須設定下列參數，以配合 Locust 多用戶同時發送交易的場景。 — --rpc-http-max-active-connections 1024，default 是100，如果沒設定超過的 connection 會被拒絕從而無法進行壓測，這個值要大於 2 個 Locust 的總併發數。
• 每次使用新的 Besu 測試參數, 需要重新部署 Besu。如果不重新部署需修改所有節點的 genesis.json 創世檔並刪除節點的 data 資料夾。
• 如果有 exception 導致節點同步錯誤，需要等待時間，待所有節點同步一致才測試下一個測項。 — 例如，nonce 的順序錯誤，需要等其它節點都同步到正確的順序，不然同步的動作會影嚮測試效能的結果。

3. 錯誤處理與陷阱

• 要注意捕捉 “Transaction nonce is too distant from current sender nonce” 的 exception，請參考 EIP-155（交易重播保護）和 EIP-681（交易 nonce 管理）。
• 這個錯誤訊息表示 交易中的 nonce 值與當前發送地址的預期 nonce 差距過大，導致節點拒絕該交易。
• 在併發的情況下，如果 nonce 順序不正確後面的request都會失敗，這是區塊鏈的機制。
• 壓測程式需要對 nonce 修正，保證壓測繼續執行。

壓測流程說明

1. 直接啟動 2 個 locust。

docker compose up -d

2. 另開 console，以 python、web3 套件，直接截取鏈上資訊 # 顯示最新的 10 個區塊中，各有多少個交易、使用多少 gas。

python3 calculate_tps.py

實測，３秒出塊的設定下，主控台所取得的TPS監測數據

3. 待壓測已持續一定時間，可以另開 console，截取、輸出最新的 n 個區塊，每 10 個區塊做一次平均值的監測資料到檔案。 — 參考更多的區塊，觀察 TPS 的平均值。

python3 calculate_tps-avg.py

檔案清單

Besu 的部署請自行參考官網說明，其餘相關程式檔案如下表：

locust-testing/
├── README.md                           # 專案說明文件
├── docker-compose.yaml                 # Docker Compose 配置檔案
├── Dockerfile                          # Docker 映像檔建構設定
├── locustfile.py                       # Locust 壓力測試主程式
├── 00-generate_accounts.py             # 產生測試用的 Web3 帳戶
├── 01-original-senders.json            # 完整的測試帳戶清單
├── 01-senders_part1_0_599.json      　 # 測試帳戶清單第1部分 (0-599)
├── 01-senders_part2_600_up.json        # 測試帳戶清單第2部分 (600以上)
├── 03-genesis-json-alloc.txt           # 創世區塊 alloc 區段的配置內容
├── calculate_tps.py                    # 計算區塊鏈網路的 TPS
├── calculate_tps-avg.py                # 計算平均 TPS 數值
├── 00-besu-metrics.txt                 # Besu 節點的效能指標記錄
├── 05-send_tx.py                       # 單次交易發送測試腳本

下載

結果與觀察

本測試採用逼近法，先以一個合適的 gasLimit 做為初次 Besu 部署標準，隨後取得效能、表現記錄後，再以 +1000萬 gas 、 -1000萬 gas 的方式調整 gasLimit，直到觀察 Besu 已無法再有更好的區塊打包處理效能，該設定即為最佳解。

以 Besu 出塊速度為 3 秒為例：

• 3,300萬 gas 為其最大工作效能。

以 besu 出塊速度為 5 秒為例：

• 4,800 萬 gas 為其最大工作效能。

延伸應用與建議

本測試的主要任務為：測得當前的硬體配置可以有多少 TPS， 所做的是 Besu 短期壓力測試，沒有部署 RPC 節點的負載平衡，讀者若有需要，可再自行進一步發揮，並建立 Grafana + Prometheus 做長時期的監控。

• 以 Besu Observer 節點監控區塊 gasLimit 耗用推算出 TPS
• 監控各 Besu RPC 節點的交易池狀態
• 監控 RPC 節點 CPU, RAM 等硬體承載狀態