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

阅读更多
个人分类: 架构 Java
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭