您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 綜合教學

Spider RPC 框架效能測試報告：百萬級 QPS 實測與調優分析

編輯：Java 綜合教學

Spider RPC 框架效能測試報告：百萬級 QPS 實測與調優分析

本文記錄 Spider RPC (高效能 Java RPC 框架) 在特定硬體環境下的完整效能基準測試過程、關鍵指標、瓶頸分析與調優建議，為分散式系統容量規劃提供參考。

一、測試環境拓撲

┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│  Client     │ ───▶  │  Spider NB  │ ───▶  │  Spider NP  │
│  (Driver)   │       │  (Broker)   │       │  (Provider) │
└─────────────┘       └─────────────┘       └─────────────┘
   200 並發              VMware VM              VMware VM
   8C/16G                4C/8G                  4C/8G
   Linux 4.19            Linux 4.19             Linux 4.19
   JDK 1.8               JDK 1.8                JDK 1.8

網路：千兆內網，平均延遲 0.3ms
序列化：Spider 私有二進制協定 (類似 Hessian2)
壓縮：Zlib 啟用 (請求 194B → 120B，響應 178B → 110B)

二、測試用例設計

1. 請求/響應模型

// Request (194 bytes)
{
  "systemId": "PL",
  "appVersion": "qq.qq.qq",
  "companyId": "12",
  "sourceIp": "DESKTOP-NDOHT79",
  "destIp": "DESKTOP-NDOHT79",
  "spiderOpts": {},
  "companyName": "機構1",
  "createDate": "20160101",
  "companyType": 1
}

// Response (178 bytes)
{
  "lists": [
    {"nodeId": 100001, "nodeName": "機構100001", "companyId": "1200", "createDate": "20160101"},
    {"nodeId": 100001, "nodeName": "機構100001", "companyId": "1200", "createDate": "20160101"}
  ]
}

2. 客戶端壓測邏輯

@RequestMapping("/1001.html")
@ResponseBody
public String t1001() {
    PlatformReq req = PlatformReq.createDemo();
    req.setCompanyId("12");
    req.setSystemId("PL");
    
    // 為壓滿 Server CPU，每次 HTTP 請求發起 5 次 RPC 調用
    platformService.doQuery(req); // 1
    platformService.doQuery(req); // 2
    platformService.doQuery(req); // 3
    platformService.doQuery(req); // 4
    platformService.doQuery(req); // 5
    return JsonUtils.toJson(platformService.doQuery(req)); // 6 (返回結果)
}

3. 服務端業務邏輯

@Service
public class PlatformServiceImpl implements PlatformService {
    public PlatformQuery doQuery(PlatformReq req) {
        // 極簡邏輯：僅構建響應物件，無 DB/外部呼叫
        return PlatformQuery.createDemo();
    }
}

三、核心測試結果

指標	數值	備註
客戶端運行總次數	≈ 1,500 萬	測試持續時長統計
Spider RPC 總調用次數	≈ 7,500 萬	客戶端次數 × 5
平均響應時間 (RT)	90 ms	含網路、序列化、業務邏輯
客戶端 QPS	2,199 TPS	HTTP 介面吞吐
Spider NB/NP 叢集 QPS	≈ 11,000 TPS	2,199 × 5 (單機 NB 處理上限)
客戶端 CPU 負載	95%~100%	壓測驅動端瓶頸
Spider NB CPU 負載	90%~95%	軟中斷佔比高 (VMware 虛擬網卡單隊列)
Spider NP CPU 負載	~60%	業務邏輯極簡，資源閒置
失敗率	< 0.01%	網路抖動導致超時

四、瓶頸深度分析

1. 軟中斷風暴 (Softirq Storm)

VMware 虛擬網卡預設單隊列 (single RX/TX queue)，所有網路封包中斷集中在 CPU 0 處理，導致單核 100% 而其他核心閒置。
證據：top -H 顯示 ksoftirqd/0 佔用 90%+ CPU，cat /proc/interrupts 顯示 eth0 中斷全在 CPU0。
參考：阿里雲 ECS 同樣受限於單隊列網卡，單機 TPS 上限約 18,000 (參考《阿里雲 ECS 單隊列網卡軟中斷優化》)。

2. 客戶端驅動能力不足

單客戶端 200 並發無法壓滿 Provider (NP CPU 僅 60%)。解決方案：增加客戶端機器、提高並發、使用專業壓測工具 (如 JMeter、nGrinder、wrk2)。

3. 序列化與壓縮開銷

Zlib 壓縮雖減少網路傳輸 (約 38%)，但增加 CPU 計算。內網高頻小包場景建議關閉壓縮，跨機房/公網啟用。

五、調優建議與擴容策略

啟用多隊列網卡 (RSS/RPS/RFS)：物理機配置 ethtool -L eth0 combined 8；雲主機選擇支援多隊列的實例規格 (如阿里雲 g7ne、c7)。
客戶端水平擴展：部署多台 Driver 機器，配合負載均衡分發壓力。
連線池優化：Spider NB 連線池大小設為 CPU 核心數 × 2~4，避免過多連線爭搶鎖。
序列化升級：評估 Protobuf、Kryo、FST 替代內建序列化，降低 CPU 佔用。
業務邏輯異步化：NP 端採用非阻塞 I/O + CompletableFuture，提高單機吞吐上限。
叢集擴容：NB 無狀態水平擴展 (DNS 轮询/LVS)；NP 按業務分片/讀寫分離。

六、監控關鍵指標儀表板

紅線指標：P99 RT > 200ms、錯誤率 > 0.1%、CPU 軟中斷 > 30%、GC 停頓 > 50ms
容量指標：QPS 趨勢、活躍連線數、隊列積壓、記憶體/堆使用率
業務指標：下單轉化率、支付成功率、核心介面可用性

七、結語

Spider RPC 在 4C/8G VMware 環境下單機 NB 可支撐 11k QPS，受限於虛擬化網路軟中斷。物理機多隊列網卡環境下預估單機 30k+ QPS。生產環境建議：物理機部署 + 多隊列網卡 + 客戶端集群壓測 + 全鏈路監控，並建立自動化效能基準回歸機制，防範版本迭代引入效能退化。