资讯专栏INFORMATION COLUMN

高性能异步RPC框架 kiss-rpc-flatbuffer介绍和测试

gclove / 3107人阅读

摘要:支持和手动编写协议两种方式。支持压缩算法,压缩速度,性能优越。单请求压缩对于单个请求进行压缩,也会根据请求的数据包压缩方式进行压缩。待开发数据加密使用多证书加密和单证书加密,更加安全。负载均衡,反向代理主动发现服务器,动态感知集群状态。

kiss-rpc特性:

1. 轻量级,简单易用。支持idl和手动编写协议两种方式。模拟函数式调用方式,更加符合rpc远程调用方式。

易修改易使用,已有的代码可以直接发布使用

数据格式支持向下兼容,采用flatbuffer协议,兼容性更好,速度更快。

支持多值返回特性,支持超时机制,类比grpc,thrift,dubbo快几倍甚至 几十倍。

支持snappy压缩算法,压缩速度,性能优越。

支持管道数据压缩,动态数据压缩,请求式数据压缩,运用场景灵活广泛。

开发环境

 * 环境: linux, unix, windows, macOS
 * 传输协议:flatbuffer for dlang(需要安装此依赖库, https://github.com/huntlabs/g...
 * 压缩协议:snappy(需要安装此依赖库, https://github.com/google/sna...
 * 开发语言:dlang
 * 编译器:dub
 * github:https://github.com/huntlabs/kiss-rpc
 * 开发者笔记:[开发笔记](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ3xapdS0TaQCk2ieqTL2UN24T))

IDL介绍和使用说明:

IDL协议编写和使用说明:IDL协议详细说明](http://e222f542.wiz03.com/sha...

关于kiss-rpc使用的压缩方式

数据压缩:使用google snappy压缩技术, 支持强制压缩和动态压缩方式,灵活的压缩方式能够运用于各种场景。

动态压缩技术: 当数据包大于200字节或者设定的阈值的时候,会压缩数据包,否则不压缩数据包,有助于空间的利用和性能的提升,response也会根据请求是否需要动态压缩数据。

单请求压缩:对于单个request请求进行压缩,response也会根据请求的数据包压缩方式进行压缩。

管道压缩: 可对指定的管道进行数据包压缩。

待开发

数据加密: 使用多证书加密和单证书加密,更加安全。

负载均衡,反向代理:主动发现服务器,动态感知集群状态。

kiss rpc 同步和异步测试:

 * 环境:ubuntu 16.04 lts(64位)
 * 硬件:xeon cpu e3-1230@3.3GHz x 8
 * 内存:8G
 * 网络:localhost(本地环回)

kiss rpc flatbuffer版本测试:

单连接 100w QPS同步测试,耗时:20秒,平均每秒5w QPS

单连接 100w QPS异步测试,   耗时5秒,平均每秒20w QPS

1000并发异步测试

1000并发, 100wQPS异步测试, 耗时:5秒,平均每秒QPS:20W

其他rpc性能对比 测试:(http://blog.csdn.net/jek12345...

**
* 海量互联网业务系统只能依赖分布式架构来解决,而分布式开发的基石则是RPC;本文主要针对两个开源的RPC框架(gRPC、 Apache Thrift),以及配合GoLang、C++两个开发语言进行性能对比分析。

测试场景client, server都是单进程,长连接,在单次连接内发起1w(5w)次rpc调用,计算耗时;
client, server都是单进程,短连接,共发起1w(5w)次连接,每次连接单次RPC调用,计算耗时;

并发4个client进程,每个进程长连接10w rpc,服务端单进程多线程(协程),计算耗时;

由于不同语言,耗时统计存在偏差,比如boost.timer在程序里计算出来的耗时明显偏小,所以统一使用linux命令time来计算耗时;

1.单进程下,长短连接,两个RPC框架和两大语言对比

小结:
整体上看,长连接性能优于短连接,性能差距在两倍以上;

对比Go语言的两个RPC框架,Thrift性能明显优于gRPC,性能差距也在两倍以上;
对比Thrift框架下的的两种语言,长连接下Go 与C++的RPC性能基本在同一个量级,在短连接下,Go性能大概是C++的二倍;
对比Thrift&C++下的TSimpleServer与TNonblockingServer,在单进程客户端长连接的场景下,TNonblockingServer因为存在线程管理开销,性能较TSimpleServer差一些;但在短连接时,主要开销在连接建立上,线程池管理开销可忽略;
两套RPC框架,以及两大语言运行都非常稳定,5w次请求耗时约是1w次的5倍;

2.多进程(线程,协程)下,两大RPC框架和两大语言对比

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/10155.html

相关文章

  • JVM并发编程模型览

    摘要:本文介绍和点评上的等并发编程模型。异步更适合并发编程。同步使线程阻塞,导致等待。基本模型这是最简单的模型,创建线程来执行一个任务,完毕后销毁线程。响应式编程是一种面向数据流和变化传播的编程模式。起源于电信领域的的编程模型。 本文介绍和点评JVM上的Thread, Thread Pool, Future, Rx, async-await, Fiber, Actor等并发编程模型。本人经验...

    cppowboy 评论0 收藏0
  • JVM并发编程模型览

    摘要:本文介绍和点评上的等并发编程模型。异步更适合并发编程。同步使线程阻塞,导致等待。基本模型这是最简单的模型,创建线程来执行一个任务,完毕后销毁线程。响应式编程是一种面向数据流和变化传播的编程模式。起源于电信领域的的编程模型。 本文介绍和点评JVM上的Thread, Thread Pool, Future, Rx, async-await, Fiber, Actor等并发编程模型。本人经验...

    wudengzan 评论0 收藏0
  • swoolefy-基于swoole扩展实现的性能的常驻内存型APIWeb应用服务框架

    摘要:是一个基于扩展实现的轻量级高性能的常驻内存型的和应用服务框架高度封装了,,服务器,以及基于实现可扩展的服务,同时支持包方式安装部署项目。基于实用,抽象事件处理类,实现与底层的回调的解耦,支持同步异步调用,内置等常用组件等。 swoolefy swoolefy是一个基于swoole扩展实现的轻量级高性能的常驻内存型的API和Web应用服务框架,高度封装了http,websocket,ud...

    lewinlee 评论0 收藏0
  • 后端必备——数据通信知识(RPC、消息队列)一站式总结

    摘要:具体可以参考消息队列之具体可以参考实战之快速入门十分钟入门阿里中间件团队博客是一个分布式的可分区的可复制的基于发布订阅的消息系统主要用于大数据领域当然在分布式系统中也有应用。目前市面上流行的消息队列就是阿里借鉴的原理用开发而得。 我自己总结的Java学习的系统知识点以及面试问题,目前已经开源,会一直完善下去,欢迎建议和指导欢迎Star: https://github.com/Snail...

    Kahn 评论0 收藏0
  • 分布式服务框架之远程通讯技术及原理分析

    摘要:微软的虽然引入了事件机制,可以在队列收到消息时触发事件,通知订阅者。由微软作为主要贡献者的,则对以及做了进一层包装,并能够很好地实现这一模式。 在分布式服务框架中,一个最基础的问题就是远程服务是怎么通讯的,在Java领域中有很多可实现远程通讯的技术,例如:RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等,这些名词之间到底是些什么关系呢,它们背后到底是基...

    sorra 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<