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

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

测试说明

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

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

测试人

南哥   mycat核心commiter     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：

 

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

Thrift：

 

Grpc：

 

测试场景

分别并发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节点

Ø  分别执行 

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

 

dubbo

Ø  启动好zk

Ø  运行startProvider.bat启动服务

Ø  分别运行

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

 

 

thrift

Ø  运行startServer.bat启动服务

 

Ø  分别运行

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

 

 

grpc

 

Ø  运行startServer.bat启动服务

 

Ø  分别运行 

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

 

 

测试结果

1客户端

测试结果如下所示：

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

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

5客户端并发

测试结果如下所示：

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

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

20客户端并发

测试结果如下所示：

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

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

50客户端并发

测试结果如下所示：

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

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

 

100客户端并发

测试结果如下所示：

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

 从数据可以看出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等测，均是如此。

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