ice-dubbo-thrift-grpc性能测试对比

短命女 2022-07-24 05:21 264阅读 0赞

**ice-dubbo-thrift-grpc性能测试对比**

# 测试说明 #

本测试只是个人为了对rpc进行技术选型，测试可能不够严谨，对某些rpc的参数可能也不是最优，如果你知道更优的参数配置或者改进意见等，[欢迎反馈给我magicdoom@gmail.com][magicdoom_gmail.com]。另外代码有些地方只是为了测试方便，不作为平时编程的范例。所有测试源码和运行均一起提供在附件里。

测试源码工程可用idea打开 [ http://git.oschina.net/whzhaochao/RPC-DEMO][http_git.oschina.net_whzhaochao_RPC-DEMO]，其中dubbo，grpc需要maven支持。运行只需要运行对应bat脚本。如果想测试更多场景，可以直接改脚本的并发数和调用次数。

## 测试人 ##

南哥 mycat核心commiter [ http://mycat.io/][http_mycat.io]

# 测试环境 #

## 测试程序 ##

由于各rpc所自带的基准测试大多跟自己的rpc耦合性比较高，不太适合拿来对多个rpc同时进行公平的测试。所以写了个简单的并发测试程序，且对个rpc保持一致性。

## 系统环境 ##

Jdk：jdk1.8.0\_51x64

Ice：ice3.6

Dubbo：dubbox 2.8.4

Thrift：0.9.2

Grpc：0.7.1

## 测试准备 ##

Ice：提前安装好ZeroC ICE 3.6，在path中设置好bin的路径。

Dubbo：准备好zookeeper

关闭杀毒软件防火墙之类以及其他一些后台程序

## 测试参数 ##

所有jvm参数均设置为java -Xms2G -Xmx2G

Ice：

![Image 1][]![Center][]

Dubbo：<dubbo:protocol name="dubbo" serialization="kryo" threads="200"/>

Thrift：

![Center 1][]![Image 1][]

Grpc：

![Center 2][]

![Image 1][]

# 测试场景 #

分别并发1、5、20、50、100个客户端程序，每个客户端程序执行300000次调用。

服务方法均通过传入一个Order对象然后原样返回。

structOrder \{  
1: i64 orderId  
2: string phone  
3: string name  
4: string orderNum  
5: i32 orderDate  
6: i32 ticketType  
7: double amount  
8: i32 orderStatus  
\}

service MobileService {
        Order hello(1:Order order),
    }

# 测试步骤 #

###  ice ###

Ø 运行registry.bat启动iceregistry

Ø 运行gridnode.bat启动icegrid节点

Ø 分别执行

![Image 1][]![Center 3][]

进行测试，测试结果在对应的benchmark\*.log里

### dubbo ###

Ø 启动好zk

Ø 运行startProvider.bat启动服务

Ø 分别运行

![Image 1][]![Center 4][]

测试，测试结果在对应的benchmark\*.log里

### thrift ###

Ø 运行startServer.bat启动服务

Ø 分别运行

![Image 1][]![Center 5][]

测试，测试结果在对应的benchmark\*.log里

### grpc ###

Ø 运行startServer.bat启动服务

Ø 分别运行

![Image 1][]![Center 6][]

测试，测试结果在对应的benchmark\*.log里

# 测试结果 #

## 1客户端 ##

测试结果如下所示：

<table> 
 <tbody> 
 <tr> 
 <td> Rpc </td> 
 <td> 并发客户端 </td> 
 <td> 每客户端调用次数 </td> 
 <td> 总调用次数 </td> 
 <td> 执行时间 </td> 
 <td> 每秒调用数tps </td> 
 </tr> 
 <tr> 
 <td> ice </td> 
 <td> 1 </td> 
 <td> 300000 </td> 
 <td> 300000 </td> 
 <td> 16s </td> 
 <td> 18329 </td> 
 </tr> 
 <tr> 
 <td> dubbo </td> 
 <td> 1 </td> 
 <td> 300000 </td> 
 <td> 300000 </td> 
 <td> 52s </td> 
 <td> 5675 </td> 
 </tr> 
 <tr> 
 <td> thrift </td> 
 <td> 1 </td> 
 <td> 300000 </td> 
 <td> 300000 </td> 
 <td> 23s </td> 
 <td> 12832 </td> 
 </tr> 
 <tr> 
 <td> grpc </td> 
 <td> 1 </td> 
 <td> 300000 </td> 
 <td> 300000 </td> 
 <td> 77s </td> 
 <td> 3896 </td> 
 </tr> 
 </tbody> 
</table>

从数据可以看出ice，thrift的tps最高，ice是thrift的1.4倍，是dubbo的3.2倍，是grpc的4.7倍

## 5客户端并发 ##

测试结果如下所示：

<table> 
 <tbody> 
 <tr> 
 <td> Rpc </td> 
 <td> 并发客户端 </td> 
 <td> 每客户端调用次数 </td> 
 <td> 总调用次数 </td> 
 <td> 执行时间 </td> 
 <td> 每秒调用数tps </td> 
 </tr> 
 <tr> 
 <td> ice </td> 
 <td> 5 </td> 
 <td> 300000 </td> 
 <td> 1500000 </td> 
 <td> 20s </td> 
 <td> 71575 </td> 
 </tr> 
 <tr> 
 <td> dubbo </td> 
 <td> 5 </td> 
 <td> 300000 </td> 
 <td> 1500000 </td> 
 <td> 77s </td> 
 <td> 19371 </td> 
 </tr> 
 <tr> 
 <td> thrift </td> 
 <td> 5 </td> 
 <td> 300000 </td> 
 <td> 1500000 </td> 
 <td> 31s </td> 
 <td> 47041 </td> 
 </tr> 
 <tr> 
 <td> grpc </td> 
 <td> 5 </td> 
 <td> 300000 </td> 
 <td> 1500000 </td> 
 <td> 95s </td> 
 <td> 15722 </td> 
 </tr> 
 </tbody> 
</table>

从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的3.6倍，是grpc的4.5倍

## 20客户端并发 ##

测试结果如下所示：

<table> 
 <tbody> 
 <tr> 
 <td> Rpc </td> 
 <td> 并发客户端 </td> 
 <td> 每客户端调用次数 </td> 
 <td> 总调用次数 </td> 
 <td> 执行时间 </td> 
 <td> 每秒调用数tps </td> 
 </tr> 
 <tr> 
 <td> ice </td> 
 <td> 20 </td> 
 <td> 300000 </td> 
 <td> 6000000 </td> 
 <td> 68s </td> 
 <td> 87375 </td> 
 </tr> 
 <tr> 
 <td> dubbo </td> 
 <td> 20 </td> 
 <td> 300000 </td> 
 <td> 6000000 </td> 
 <td> 256s </td> 
 <td> 23354 </td> 
 </tr> 
 <tr> 
 <td> thrift </td> 
 <td> 20 </td> 
 <td> 300000 </td> 
 <td> 6000000 </td> 
 <td> 94s </td> 
 <td> 63708 </td> 
 </tr> 
 <tr> 
 <td> grpc </td> 
 <td> 20 </td> 
 <td> 300000 </td> 
 <td> 6000000 </td> 
 <td> 382s </td> 
 <td> 15675 </td> 
 </tr> 
 </tbody> 
</table>

从数据可以看出ice，thrift的tps最高，ice是thrift的1.3倍，是dubbo的3.7倍，是grpc的5.5倍

## 50客户端并发 ##

测试结果如下所示：

<table> 
 <tbody> 
 <tr> 
 <td> Rpc </td> 
 <td> 并发客户端 </td> 
 <td> 每客户端调用次数 </td> 
 <td> 总调用次数 </td> 
 <td> 执行时间 </td> 
 <td> 每秒调用数tps </td> 
 </tr> 
 <tr> 
 <td> ice </td> 
 <td> 50 </td> 
 <td> 300000 </td> 
 <td> 15000000 </td> 
 <td> 165s </td> 
 <td> 90679 </td> 
 </tr> 
 <tr> 
 <td> dubbo </td> 
 <td> 50 </td> 
 <td> 300000 </td> 
 <td> 15000000 </td> 
 <td> 676s </td> 
 <td> 22157 </td> 
 </tr> 
 <tr> 
 <td> thrift </td> 
 <td> 50 </td> 
 <td> 300000 </td> 
 <td> 15000000 </td> 
 <td> 255s </td> 
 <td> 58765 </td> 
 </tr> 
 <tr> 
 <td> grpc </td> 
 <td> 50 </td> 
 <td> 300000 </td> 
 <td> 15000000 </td> 
 <td> 987s </td> 
 <td> 15186 </td> 
 </tr> 
 </tbody> 
</table>

从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的4倍，是grpc的5.9倍

## 100客户端并发 ##

测试结果如下所示：

<table> 
 <tbody> 
 <tr> 
 <td> Rpc </td> 
 <td> 并发客户端 </td> 
 <td> 每客户端调用次数 </td> 
 <td> 总调用次数 </td> 
 <td> 执行时间 </td> 
 <td> 每秒调用数tps </td> 
 </tr> 
 <tr> 
 <td> ice </td> 
 <td> 100 </td> 
 <td> 300000 </td> 
 <td> 30000000 </td> 
 <td> 361s </td> 
 <td> 83014 </td> 
 </tr> 
 <tr> 
 <td> dubbo </td> 
 <td> 100 </td> 
 <td> 300000 </td> 
 <td> 30000000 </td> 
 <td> 1599s </td> 
 <td> 18760 </td> 
 </tr> 
 <tr> 
 <td> thrift </td> 
 <td> 100 </td> 
 <td> 300000 </td> 
 <td> 30000000 </td> 
 <td> 597s </td> 
 <td> 50211 </td> 
 </tr> 
 <tr> 
 <td> grpc </td> 
 <td> 100 </td> 
 <td> 300000 </td> 
 <td> 30000000 </td> 
 <td> 2186s </td> 
 <td> 13721 </td> 
 </tr> 
 </tbody> 
</table>

从数据可以看出ice，thrift的tps最高，ice是thrift的1.6倍，是dubbo的4.4倍，是grpc的6倍

# 总结 #

从测试结果可以看出ice的tps遥遥领先，而且并发越高tps比其他越高，其次thrift，dubbo和grpc则差了很多。Grpc最差估计跟用了HTTP2有关。

另外dubbox还支持rest，官方测试rest比kyro要慢1.5倍，本次未对rest测试。

从功能完备性来说ice和dubbo都算比较完备，都有大型生产案例，thrift的服务化功能比较缺失，grpc可能还不够成熟。

Dubbo的插件化机制的确不错，ice初次接触有些概念比较晦涩，经过封装和有详细的资料后要好上许多。

另外《Zeroc Ice权威指南》作者Leader-us对ice的测试结果如下：

**Leader-us测试结果Ice则是2.5万，性能差不多是Avro的一倍，综合起来看Avro和thrift的性能应该差不多。**

• Apache Avro框架简单，非接口编译的模式灵活度很高，用Json定义的RPC消息结构和方法简单并容易理解

•Http协议的编码和传输机制效率远远低于长连接的Socket模式，本机对比了Avro的Http协议与Netty实现的Socket协议，请求应答消息相同的情况下，HTTP的TPS是500左右，而Netty Socket模式则是1.5万左右，相差很悬殊

•多语言客户端支持并不是那么容易的事情，Avro的Python客户端目前只实现了基本的Http协议，（Java的同时实现了Netty客户端协议），这种情况下，服务端只能也采用Http协议，从而导致并发性能问题

# 支付宝的一个惊人秘密 #

在测试icegrid的过程中发现性能比较直接连server的方式性能下降了40%，通过几天的调测，调过各种参数配置均未发现原因。直到一次测试过程中偶然打开任务管理器，看到了这货

Alipay security business service占用cpu异常偏高，把这个服务停掉，再测试，刷刷性能恢复正常了。

再反复测试几次，用dubbo等测，均是如此。

![Image 1][]![Center 7][]

Alipay securitybusiness service应该了拦截了所有的网络流量，拦截程序可能写的有问题，但是。。。。。。你拦截跟支付宝淘宝有关的流量就好，为啥其他流量全拦截呢，至于有没有把流量偷偷传回服务器这个有待进一步监测。

[magicdoom_gmail.com]: mailto:%E6%AC%A2%E8%BF%8E%E5%8F%8D%E9%A6%88%E7%BB%99%E6%88%91magicdoom@gmail.com
[http_git.oschina.net_whzhaochao_RPC-DEMO]: http://git.oschina.net/whzhaochao/RPC-DEMO
[http_mycat.io]: http://mycat.io/
[Image 1]: 
[Center]: /images/20220722/b833f4ed2cb54c5cb10c86e286abbd55.png
[Center 1]: https://img-blog.csdn.net/20160514161236108?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
[Center 2]: /images/20220722/e83bfc17ee544bbe84b0409b09b8a213.png
[Center 3]: /images/20220722/ef17cae6acb044eda02421543861e04c.png
[Center 4]: /images/20220722/3a94ac74d6134953bc893ea0a641641c.png
[Center 5]: /images/20220722/2ef858413ff74e5e93ae651b9463b8f1.png
[Center 6]: /images/20220722/9afd61396f0d4031a5d9f58eebcd13a6.png
[Center 7]: /images/20220722/a8ab854798ea4ffcb1b72ee972de7fcd.png