Dubbo性能优化

https://my.oschina.net/u/1378920/blog/739399

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这些不足做一些扩展