Dubbo-线程池调优实战分析

Dubbo的线程池压测调优

dubbo的服务提供者端一共包含了两类线程池，一类叫做io线程池，还有一类叫做业务线程池，它们各自有着自己的分工，如下图所示

dubbo在服务提供方中有io线程池和业务线程池之分。可以通过调整相关的dispatcher参数来控制将请求处理交给不同的线程池处理。（下边列举工作中常用的几个参数：）

all：将请求全部交给业务线程池处理（这里面除了日常的消费者进行服务调用之外，还有关于服务的心跳校验，连接事件，断开服务，响应数据写回等）

execution：会将请求处理进行分离，心跳检测，连接等非业务核心模块交给io线程池处理，核心的业务调用接口则交由业务线程池处理。

假设说我们的dubbo接口只是一些简单的逻辑处理，例如说下方这类:

@Service(interfaceName = "msgService")
public class MsgServiceImpl implements MsgService {

    @Override
    public Boolean sendMsg(int id, String msg)  {
            System.out.println("msg is :"+msg);
            return true;
    }
}

并没有过多的繁琐请求，并且我们手动设置线程池参数

dubbo.protocol.threadpool=fixed
dubbo.protocol.threads=10
dubbo.protocol.accepts=5

当线程池满了的时候，服务会立马进入失败状态，此时如果需要给provider设置等待队列的话可以尝试使用queues参数进行设置。

dubbo.protocol.queues=100

但是这个设置项虽然看似能够增大服务提供者的承载能力，却并不是特别建议开启，因为当我们的provider承载能力达到原先预期的限度时，通过请求堆积的方式继续请求指定的服务器并不是一个合理的方案，合理的做法应该是直接抛出线程池溢出异常，然后请求其他的服务提供者。

测试环境：

Mac笔记本，jvm：-xmx 256m -xms 256m

接着通过使用jmeter进行压力测试，发现一秒钟调用100次（大于实际的业务线程数目下，线程池并没有发生溢出情况）。这是因为此时dubbo接口中的处理逻辑非常简单，这么点并发量并不会造成过大影响。（几乎所有请求都能正常抗住）

但是假设说我们的dubbo服务内部做了一定的业务处理，耗时较久，例如下方：

@Service(interfaceName = "msgService")
public class MsgServiceImpl implements MsgService {

    @Override
    public Boolean sendMsg(int id, String msg) throws InterruptedException {
            System.out.println("msg is :"+msg);
            Thread.sleep(500);
            return true;
    }
}

此时再做压测，解果就会不一样了。

此时大部分的请求都会因为业务线程池中的数目有限出现堵塞，因此导致大量的rpc调用出现异常。可以在console窗口看到调用出现大量异常：

将jmeter的压测报告进行导出之后，可以看到调用成功率大大降低，

也仅仅只有10%左右的请求能够被成功处理，这样的服务假设进行了线程池参数优化之后又会如何呢？
1秒钟100个请求并发访问dubbo服务，此时业务线程池专心只处理服务调用的请求，并且最大线程数为100，服务端最大可接纳连接数也是100，按理来说应该所有请求都能正常处理

dubbo.protocol.threadpool=fixed
dubbo.protocol.dispatcher=execution
dubbo.protocol.threads=100
dubbo.protocol.accepts=100

还是之前的压测参数，这回所有的请求都能正常返回。

ps：提出一个小问题，从测试报告中查看到平均接口的响应耗时为：502ms，也就是说其实dubbo接口的承载能力估计还能扩大个一倍左右，我又尝试加大了压测的力度，这次看看1秒钟190次请求会如何？（假设线程池100连接中，每个连接对请求的处理耗时大约为500ms，那么一秒时长大约能处理2个请求，但是考虑到一些额外的耗时可能达不到理想状态那么高，因此设置为每秒190次（190 <= 2*100）请求的压测）

但是此时发现请求的响应结果似乎并没有这么理想，这次请求响应的成功率大大降低了。

其实主要原因是当线程池满了的时候，服务会立马进入失败状态，而jmeter产生的压测线程数目并不是均匀的，可能190个线程的80%是在1s内的后0.5s中产生，这种情况下是会造成dubbo服务承载失败的。