RPC 協議 Triple&Dubbo 效能基準測試
- Dubbo3 的 *Dubbo 協議* 實現在效能方面與 Dubbo2 版本基本相同。
- 由於 Triple 協議本身是基於 HTTP/2 構建的，因此單一鏈路上的 RPC 呼叫與基於 TCP 的 Dubbo2 相比並沒有提升，在某些呼叫情境下甚至有所下降。但 _Triple 協議_ 的更大優勢在於閘道器穿透性、通用性以及 Stream 通訊模型帶來的整體吞吐量提升。
- 預計 Triple 在閘道器代理情境下會有更好的效能。鑑於目前的壓力測試環境，本輪基準測試尚未提供。
1.1 環境
| | 說明 | | ———— | ———————————— ———————— | | **機器** | 4 核心 8GB 記憶體 Linux JDK 1.8 (提供者) 4 核心 8GB 記憶體 Linux JDK 1.8 (消費者) | | **壓力測試案例** | RPC 方法類型包括：無參數且無回傳值、一般 pojo 回傳值、pojo 列表回傳值
2.7 版本 Dubbo 協議 (Hessian2 序列化)
3.0 版本 Dubbo 協議 (Hessian2 序列化)
3.0 版本 Dubbo 協議 (Protobuf 序列化)
3.0 版本 Triple 協議 (Protobuf 序列化)
3.0 版本 Triple 協議 (Protobuf 設定 Hessian2 序列化) | | **壓力測試方法** | 在單一鏈路情境下，消費者啟動 32 個併發執行緒（目前機器配置 qps rt 的併發數較為均衡），並在持續壓力後收集壓力測試數據
壓力測試數據通過 https: //github.com/apache/dubbo-benchmark 獲取 |
1.2 數據分析
| | **Dubbo + Hessian2
2.7** | **Dubbo + Hessian2
3.0** | **Dubbo + Protobuf
3.0** | **Triple + Protobuf
3.0** | **Triple + Protobuf(Hessian)
3.0** | | —————— | —————————– | —————————– | ——————– ——— | —————————— | ——— ——————————— | | **無參數方法** | 30333 ops/s
2.5 毫秒 P99 | 30414 ops/s
2.4 毫秒 P99 | 24123 ops/s
P99 3.2 毫秒 | 7016 次操作/秒
P99 8.7 毫秒 | 6635 次操作/秒
P99 9.1 毫秒 | | POJO 返回值 | 8984 次操作/秒
P99 6.1 毫秒 | 12279 次操作/秒
P99 5.7 毫秒 | 21479 次操作/秒
P99 3.0 毫秒 | 6255 次操作/秒
P99 8.9 毫秒 | 6491 次操作/秒
P99 10 毫秒 | | POJO 列表返回值 | 1916 次操作/秒
P99 34 毫秒 | 2037 次操作/秒
P99 34 毫秒 | 12722 次操作/秒
P99 7.7 毫秒 | 6920 次操作/秒
P99 9.6 毫秒 | 2833 次操作/秒
P99 27 毫秒 |
1.2.1 不同版本 Dubbo 協議比較
圖 3 不同版本 Dubbo 協議實作比較
- 就 Dubbo RPC + Hessian 的預設組合而言，Dubbo3 和 Dubbo2 在不同的調用場景下的效能基本相同。
1.2.2 Dubbo 協議 vs Triple 協議
圖 4 Triple vs Dubbo
- 單純從消費者 <-> 提供者的點對點調用來看，Triple 協議本身並不佔優勢。同樣使用 Protobuf 序列化方式，Dubbo RPC 協議的整體效能仍然優於 Triple。
- Triple 實作在 3.0 版本中會持續優化，但無法完全改變「基於 HTTP/2 的 RPC 協議」在某些場景下相較於「基於 TCP 的 RPC 協議」的劣勢。
1.2.3 補充閘道器場景
待辦 (TBD)
1.2.4 模擬 Stream 通信場景的吞吐量提升
待辦 (TBD)
