Dubbo性能优化

Dubbo性能优化

背景

dubbo做为一款分布式服务框架，除了提供远程调用的细节封装，还提供了基本的服务治理功能，可以粗略地监控系统性能。

上图展现的是dubbo执行流程的原理图，在客户端和服务端都有一个程序去统计调用信息，其中有价值的信息有延迟时间、并发数、调用次数等，完成记录以后，客户端和服务端分别会定时发送到监控平台，监控平台汇总以后，算出平均qps(每秒调用次数)和平均rt(每次调用延时)等数据并展示在监控平台页面上

最近公司用上了dubbo做为dsp引擎和算法平台之间的一个分布式服务框架，目的是解开引擎和算法之间的强耦合。

• 消费者--客户端--dsp引擎
• 提供者--服务端--算法平台

现象

根据dubbo监控平台观察到的现象（红线为客户端数据，蓝线为服务端数据）

• 线上QPS

• 线上RT

问题描述

根据dubbo监控平台现象得知，qps较低时，客户端rt并不高，可是qps较大时，客户端rt很是高，而且持续稳定在10ms左右。这对于性能要求很高的广告引擎是没法容忍的。

###线上环境

14台客户端，5台服务端，配置信息：24核cpu+64g内存+1000MB/s带宽

优化过程

延迟较高，就得先查看资源使用有没有出现瓶颈的地方。根据监控信息显示，服务端延迟基本为0，客户端延迟很高。因此颇有多是客户端出现了瓶颈，因此重点先放到客户端这一边，先肯定一台客户端的机器（10.100.51.175）来分析问题。

• 总体环境

因为目前rpc调用中使用到的资源主要有cpu、内存、网络，因为不存在磁盘I/O，因此排除掉这个资源的影响。

• CPU：

性能有问题，首先派上用场的工具就是top。top能够粗略检测cpu使用状况。

因而可知总cpu使用率并不高。接着用vmstat查看cpu上等待和正在运行的任务

看到等待的任务并很少，不过这里能够看到cs上下文切换较高，有多是线程较多致使不少竞争。这个可能会影响到性能，先记录下来。

上面提到的都是对cpu总体排查的方式，接着也不要漏过对每一个cpu进行排查的方式。使用mpstat检查每个cpu

看到没有一个cpu处于繁忙状态

• 内存：

根据上述top工具截图，能够发现64g内存绝大部分都被分配给了应用程序，可是经过进程信息区能够查看到每一个进行对内存使用率并不高。

根据上述vmstat工具截图，能够观察到si(换入的内存)和so(换出的内存)都是0，因此系统不会由于内存换页而产生性能问题。

• 网络：

先使用ethtool来检测一下网卡eth0的带宽

发现确实是千兆网卡。那么在千兆网卡上面，咱们程序的利用率能达到多少呢？可使用一个叫nicstat的工具来统计利用率

从上图能够发现，咱们的网络利用率很低(%Util)，也没有出现丢包(Drops)的状况，说明咱们数据传输速度较慢，这个多是问题所在，暂时先记录下来。

• 程序环境

从总体上只能大概有个方向，具体排查还得从程序自己着手。这时就得根据线上环境，模拟一个测试平台，在测试平台来定位问题所在，分析程序到底哪里慢。

我在10.100.52.164上搭建了测试环境的服务端，和引擎团队在10.100.51.151上搭建的客户端端进行打通，完成对线上环境的模拟。环境搭建好了，接着我使用tcpcopy将线上机器的流量引入到了个人测试环境。流量打通以后，查看监控平台，发现随着流量的扩大，问题立刻暴露了出来：目前qps在1w的状况下，客户端rt达到了17ms左右。

测试环境与线上环境的现象基本一致：qps较大的状况下，客户端rt变得很是高，服务端rt几乎为0。因此瓶颈应该在客户端。接着，咱们能够利用火焰图来分析测试环境下客户端哪一个步骤比较慢

根据火焰图能够定位到统计调用时间的代码处，MonitorFilter类的invoke方法。既然是从这里统计到延迟较高，那么问题确定出如今invoke调用链里面的某个方法。根据火焰图继续往上分析调用栈，看到左边的DefaultFuture的get方法和右边OneToOneEncoder的doEncode方法各占了很大一部分比例。那么这两个方法究竟是干什么的呢？

• DefaultFuture.get:客户端同步等待服务端响应。因为dubbo协议采用的是netty异步写，而后同步等待服务端响应的一种模式。因此这里至关于客户端等着服务端完成本地调用以后将执行结果返回回来的一个过程。

• OneToOneEncoder.doEncode:客户端编码。这个步骤主要也就是对参数、方法名、接口名等信息的序列化操做。

使用btrace分别测出两个方法的执行时间的分布图

• DefaultFuture.get方法执行时间

时间大部分集中在16ms,在客户端17ms的延迟表现中占了绝大部分

• OneToOneEncoder.doEncode方法执行时间

时间大部分集中在0ms

发现doEncode虽然对cpu利用的较多，可是不怎么消耗时间。真正消耗时间的是get方法。能够经过一张图来了解get操做等待的时候，后台到底作了哪些操做。

因此程序颇有多是卡在网络读写上面。

• 猜想

文章前部分有一张使用nicstat抓取的网络读写状态，发现网络利用率很低，也就是网络读写速度都很慢。可是使用ping网络发现网络速度并不慢，可是为何在程序中，qps较大时，网络读写速度就会很慢？

若是是网络堵塞而致使速度很慢。那么也就是客户端的发送窗口和服务端接口窗口设置的过小，或者客户端TCP发送缓存和服务端TCP接收缓存过小，当客户端发起大量数据请求时，服务端没法及时处理这些数据，那么服务端就会选择性的丢掉一部分包。可是根据上图nicstat截图发现，几乎没有产生丢包现象，并且我本身也尝试过调大这些参数，发现仍是没有什么做用。因此这种可能性能够排除。

翻阅《TCP/IP详解（协议）》以后，查得还有一种可能性会致使网络速度很慢，就是TCP的拥塞控制。为了减小丢包而引起的性能损失，它会先预估线路中的拥挤状况，而后来控制客户端发送的流量。这极可能就是致使网路速度提不起来的一个关键因素。并且，目前使用dubbo协议的默认单一长链接模式，也就是只有一个网络读写通道。当这个通道某个方向的网络传输量大了以后，就容易引发堵塞，TCP协议为了避免产生堵塞而丢包，就进而控制了客户端的数据传送速度。

• 处理

既然是一条线路的传输量太大而致使被"限速"，那么能够试试开辟多条线路。也就是将原来客户端-服务端单一长链接模式改为客户端-服务端多长链接模式。

结果

在测试环境下，加大了链接个数以后，测试环境的延迟下降了。而在线上环境，改为多长链接以后，在qps不变的状况下，延迟从平均10ms降到了平均1ms。

下面是稳定以后，监控平台记录的线上环境的qps和rt数据

• 线上QPS-优化后

• 线上RT-优化后

发现增长了长链接个数以后，延迟下降了，性能提高了。不过因为目前每台服务端监听14台客户端，客户端每增长一个长链接就会致使服务端长链接增长14个，若是链接过多，就会由于带宽资源不够而出现瓶颈，因此要根据线上实际状况来调整长链接个数。

思考

调用完成了，可是思考尚未中止。经过此次经历，也算发现了dubbo的一些弊端。做为一款致力于提供服务的框架，dubbo的问题发现能力还有待完善。

• dubbo监控平台只显示了全部服务端、客户端的总体性能指标，缺乏单台机器的指标显示
• dubbo监控平台只能统计平均rt和平均qps，平均值自己就是很是不清晰的指标，采用百分比分布统计的方式会更好
• dubbo监控平台没有提供报警功能，没有办法及时发现问题

综上所述，dubbo还有值得完善，后续能够对dubbo这些不足作一些扩展

参考文献

• TCP/IP详解 卷1：协议（https://book.douban.com/subject/1088054/）
• 性能之巅（https://book.douban.com/subject/26586598/）
• HTTP权威指南完整版（https://book.douban.com/subject/10746113/）
• dubbo官方文档（http://dubbo.io/Home-zh.htm）
• dubbox源代码（https://github.com/dangdangdotcom/dubbox）