公司內(nèi)部的RPC框架，經(jīng)過長時間的發(fā)展，已經(jīng)由完全自研演進(jìn)到底層替換為Dubbo實(shí)現(xiàn)，但使用方式（API）還是不變。由于使用了PB序列化協(xié)議，以及業(yè)務(wù)碼+操作碼定義接口的方式，非常影響開發(fā)效率，可理解性差，鏈路排查困難等問題，不斷被業(yè)務(wù)方吐槽。因此就有了第三個版本，繼續(xù)基于Dubbo擴(kuò)展點(diǎn)，設(shè)計(jì)開發(fā)提供接近Dubbo原生的使用方式。

由于Dubbo原生提供的Http rpc協(xié)議的實(shí)現(xiàn)，不僅使用了Spring框架的API，還使用了Java的原生序列化，所以我們基于擴(kuò)展點(diǎn)自實(shí)現(xiàn)了Http rpc協(xié)議，移除對Spring的強(qiáng)依賴，并使用json序列化協(xié)議。此次性能測試對比的是我們基于Dubbo擴(kuò)展點(diǎn)自實(shí)現(xiàn)的Http rpc協(xié)議，與Dubbo原生Dubbo rpc協(xié)議的單次請求響應(yīng)平均耗時、吞吐量。

• Dubbo rpc：Dubbo rpc協(xié)議 + hessian2序列化協(xié)議

• Http rpc：Http rpc協(xié)議（服務(wù)端使用jetty，客戶端使用netty） + json序列化協(xié)議（使用fastjson）

基準(zhǔn)測試目的

• 在最初設(shè)計(jì)評審時，關(guān)于是采用http協(xié)議還是dubbo協(xié)議，我們對這兩者在性能方面的影響還存在疑慮。

• 有Dubbo rpc的性能數(shù)據(jù)做對比，對自實(shí)現(xiàn)的Http rpc，性能應(yīng)該優(yōu)化到多少才算最優(yōu)，心里有個底。

基準(zhǔn)測試接口

接口實(shí)現(xiàn)不做任何業(yè)務(wù)處理，排除業(yè)務(wù)耗時對基準(zhǔn)測試的影響。

RPC接口定義：

public interface DemoeService {Result<String> sayHello(String name); }

提供者實(shí)現(xiàn)：

@ServiceProvider public class DemoeServiceImpl implements DemoeService {@Overridepublic Result<String> sayHello(String name) {Result<String> result = new Result<>(0, name);return result;} }

基準(zhǔn)測試說明

一、以相同配置，不同rpc協(xié)議實(shí)現(xiàn)注冊DemoService服務(wù)提供者。

服務(wù)提供者參數(shù)配置如下：

• 工作線程數(shù)：200 （處理業(yè)務(wù)）

• IO線程數(shù)：4 （處理數(shù)據(jù)包的讀寫、編解碼）

二、以相同配置，不同rpc協(xié)議創(chuàng)建DemoService服務(wù)消費(fèi)者。

唯一的區(qū)別是，使用http rpc協(xié)議需要配置連接池，使用dubbo rpc協(xié)議只配置單一長連接。

使用http rpc協(xié)議，服務(wù)消費(fèi)者連接池配置：

• 最大連接數(shù)：無最大連接數(shù)限制；

• 最大空閑連接數(shù)：1024；

三、使用open-jdk官方開源的JMH基準(zhǔn)測試工具對DemoService接口分別進(jìn)行平均耗時測量、吞吐量測量。

環(huán)境

• 本地測試，MacBook Pro 8核16G

• 盡量關(guān)閉多余進(jìn)程

• 先啟動dubbo協(xié)議服務(wù)提供者和消費(fèi)者，測完dubbo協(xié)議后，再測http協(xié)議

• dubbo版本：2.6.4 （二次開發(fā)過，增加了一些功能特性）

基準(zhǔn)測試結(jié)果

Http rpc與Dubbo rpc基準(zhǔn)測試：

• 測量指標(biāo)：平均耗時、吞吐量

• 預(yù)熱1次，每次5秒鐘

• 測量5次，每次5秒鐘

• 消費(fèi)者線程數(shù)200（模擬并發(fā)）

• 數(shù)據(jù)包足夠小（調(diào)用的接口信息+參數(shù)，數(shù)據(jù)包小于1KB）

初次測試

Http rpc測量結(jié)果：

Benchmark Mode Cnt Score Error Units HttpConsumerBenchmarkTest.testHttp thrpt 5 1.408 ± 0.235 ops/ms HttpConsumerBenchmarkTest.testHttp avgt 5 233.966 ± 163.614 ms/op

Dubbo rpc測量結(jié)果：

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 42.829 ± 24.597 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 4.739 ± 0.192 ms/op

測量結(jié)果對比

	吞吐量	平均耗時
http rpc	1408ops	233.966ms
dubbo rpc	42829ops	4.739ms

此次測試結(jié)果數(shù)據(jù)差別有些大，初步定位耗時在服務(wù)端。

經(jīng)關(guān)鍵步驟打印日記后發(fā)現(xiàn)，數(shù)據(jù)序列化和反序列化耗時比較嚴(yán)重。

經(jīng)驗(yàn)證后，發(fā)現(xiàn)fastjson序列化和反序列化泛型非常耗時，并且改用gson后耗時降低，性能數(shù)據(jù)表現(xiàn)接近Dubbo rpc。

優(yōu)化后重新測試

HTTP rpc（使用json + gson）

Benchmark Mode Cnt Score Error Units HttpConsumerBenchmarkTest.testHttp thrpt 5 31.550 ± 6.477 ops/ms HttpConsumerBenchmarkTest.testHttp avgt 5 6.487 ± 1.512 ms/op

Dubbo rpc（使用hessian2）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 42.829 ± 24.597 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 4.739 ± 0.192 ms/op

考慮到序列化協(xié)議也是影響性能的重要因素，因此我們增加了Dubbo rpc使用json序列化協(xié)議的基準(zhǔn)測試。

Dubbo（序列化使用fastjson）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 21.416 ± 7.571 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 9.687 ± 2.329 ms/op

Dubbo（序列化使用gson）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 24.460 ± 7.396 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 7.743 ± 1.256 ms/op

可以看到，同樣使用json序列化協(xié)議，且使用gson工具，Http rpc與Dubbo rpc性能相差在0.5～1ms之間，并且Http rpc的耗時略低，吞吐量更高；Dubbo rpc同樣使用json序列化協(xié)議，使用gson工具與fastjson工具性能相差2ms左右，fastjson性能表現(xiàn)較差。

此測試數(shù)據(jù)僅供參考！

官方性能壓測報告：性能測試報告

總結(jié)

以上是生活随笔為你收集整理的Dubbo之HTTP RPC vs Dubbo RPC性能压测的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。