dubbo vs mac-rpc 之性能评测一


声明:本文转载自https://my.oschina.net/u/162831/blog/1648023,转载目的在于传递更多信息,仅供学习交流之用。如有侵权行为,请联系我,我会及时删除。

插播一条广告→2021 ByteDance字节跳动内推←各城市、各方向的岗位都有,大量招人!


  Dubbo 是阿里巴巴开源的一款Java高性能分布式微服务框架。它以远程方法调用功能为基础,将系统中的服务以远程方法调用(RPC)的形式暴露并管理,提供配套的面向服务(SOA)的治理手段,从而形成完整的分布式微服务框架体系。

  Dubbo项目大概始于2009年,但不知出于什么原因,官方于2012年停止了维护。颇有戏剧性的是,墙内开花墙外香,Dubbo受到国内很多第三方厂商的欢迎,并在其项目中广泛使用。因此,官方于2017年重启Dubbo项目的维护,目前最新版本是2.6.1。

  mac-rpc是一款新的基于Java AIO的开源RPC框架,小巧精悍。强大的异步能力是它最大的亮点。Dubbo在异步支持上比较弱,而mac-rpc天生就是异步的,使得mac-rpc在异步方法调用的性能方面颇具优势。(了解其实现原理请访问官方网站 www.boarsoft.com)。

  作为RPC框架,大多数的应用场景都是同步方法调用。而mac-rpc在同步方法调用方面的性能也非常不俗,可以与dubbo一较高下。因此,笔者仅对两者的同步方法调用的性能进行对比测试

一、测试环境

  硬件:笔记本电脑一台 CPU Intel i5-6300HQ @2.30GHz,8G内存

  软件:JDK1.7、dubbo 2.6.1、mac-rpc 1.0.1

  注:笔记本电脑在CPU温度过高时会自动降频,导致测试结果的波动。笔者不得不采用轮流执行,多次测试取平均值的方式进行。所得数据可能并不很准确,但能从大体上看出两者的性能水平。

二、测试场景

  Dubbo可调参数众多,其调优过程本身就已非常复杂,费时费力。因此,本次测试将尽可能采用其默认参数。经过多轮测试,Dubbo在采用固定大小线程池时性能表现最佳,同时为了避免dubbo抛出线程池耗尽的异常,我们将服务方的线程池大小固定为600,在消费方使用300个线程并行发起调用。

  另外,dubbo在传输大对象时表现不佳,过大的数据量将导致dubbo的性能严重下降。因此我们只让测试程序拼装并返回10~1万个字符。因为实际应用过程中,绝大多数RPC方法调用,一次调用通过网络往返的数据量大致都位于这个区间内。

  注:作为RPC框架,在方法调用时只传输小对象是可以的。但作为微服务框架,系统内服务的形式多种多样,如果限制所有服务都不能返回大对象,似乎有一些差强人意。在这一点上mac-rpc则更具优势。

三、测试要点

  在生产实践中,我们可以看到这样一种现象,单笔测试时,只需要几个毫秒,甚至零毫秒的服务,在压力测试或生产环境下,延迟到几十、数百毫秒,有的甚至数秒,直到超过规定的响应时长。导致这一现象的原因有很多,包括:磁盘IO、网络IO、线程切换、锁等待、CPU负载过高,内存不足,频繁GC、第三方系统时延等等。经常会发现系统吞吐量低,响应缓慢时,各项物理资源消耗却很少。

  为了更真实的模拟生产的运行环境,我们在方法中通过Thread.sleep来模拟以上各种原因造成的时延。观察RPC方法调用在受这些因素影响下的实际性能表现。此外,在大压力的情况下,输入输出数据量的大小对性能也有显著影响,我们还需要测试不同数据量下的性能表现。

  还有一个重要一因素就是微服务的粒度,服务粒度越小,灵活度越高,但在系统中相互调用的开销就越大,管理起来也更加复杂。适当的粒度对提高系统的吞吐量非常重要。

三、测试方法

  服务消费者使用300线程并行的发起同步RPC方法调用,服务提供者采用固定600个线程的线程池。模拟在0ms、10ms、20ms、50ms、100ms时延下,数据量在10、1000、5000、10000个字符时的表现。

  同时为了避免磁盘IO和网络IO对性能的影响,测试程序不打日志,不写磁盘。服务消费者和服务提供者都在同一台电脑上。

  注:由于长时延和大数据量时,测试耗时急剧增加,为了节省时间,随着时延加长、数据量的加大,每线程的调用次数相应的被减少到5000次或2000次。

四、测试结果

  注:每线程 = 每线程发起的调用次数

  

五、资源消耗

  资源上看,Dubbo的线程池使用SynchronousQueue队列,这意味着服务消费者通过300个线程发起调用时,服务提供者对应的也会调起300个线程来执行。而mac-rpc的线程池默认使用LinkedBlockingQueue,使得服务消费者的线程数对服务提供者无影响。同时,mac-rpc默认采用CallerRunsPolicy作为线程不足的处理策略,而dubbo则采用AbortPolicy,除非采用cached线程池,否则当线程不足时,dubbo将抛出RejectedExecutionException。无论从配置方便程度,还是灵活度,mac-rpc都更优。

  在使用固定600个线程的线程池的情况下,mac-rpc在CPU使用(25%)上略高于dubbo(20%),在内存使用上则显著优于dubbo(50~200M),稳定在50M左右。

dubbo 服务提供方资源消耗:

mac-rpc 服务提供方资源消耗:

六、测试结论

  当时RPC方法的时延较小,且数据量也较小,在此例中约为小于15ms,字节数小于大约2000~3000个时,Dubbo较mac-rpc有明显优势。之后随着时延和数据量的增加,mac-rpc的优势逐渐显现,响应时间和TPS都相对平稳,而dubbo的性能则显著下降,差距较大。继续增大压力,dubbo的表现会更糟糕,mac-rpc则相对更好一些。

  综合来看,mac-rpc在同步方法调用方面,相较dubbo,有着更优秀的性能表现,稳定性也更好,能够更好的承受压力。目前mac-rpc已具备了简单的微服务治理能力,但由于作者精力有限,发展时间较短,在功能性和治理手段方面还有待完善和加强。

本文发表于2018年03月20日 22:38
(c)注:本文转载自https://my.oschina.net/u/162831/blog/1648023,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如有侵权行为,请联系我们,我们会及时删除.

阅读 935 讨论 0 喜欢 0

抢先体验

扫码体验
趣味小程序
文字表情生成器

闪念胶囊

你要过得好哇,这样我才能恨你啊,你要是过得不好,我都不知道该恨你还是拥抱你啊。

直抵黄龙府,与诸君痛饮尔。

那时陪伴我的人啊,你们如今在何方。

不出意外的话,我们再也不会见了,祝你前程似锦。

这世界真好,吃野东西也要留出这条命来看看

快捷链接
网站地图
提交友链
Copyright © 2016 - 2021 Cion.
All Rights Reserved.
京ICP备2021004668号-1