Dubbo-线程池调优实战分析

简介: 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服务承载失败的。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
3天前
|
Java
【Java多线程】分析线程加锁导致的死锁问题以及解决方案
【Java多线程】分析线程加锁导致的死锁问题以及解决方案
25 1
|
3天前
|
Java
Java中的多线程编程:基础知识与实战技巧
【5月更文挑战第6天】多线程编程是Java中的一个重要特性,它允许我们在一个程序中同时执行多个任务。本文将介绍Java多线程的基础知识,包括线程的创建、启动、同步和通信,以及如何在Java中实现多线程编程。通过实例代码和解析,帮助读者深入理解Java多线程编程的概念和应用。
|
3天前
|
设计模式 算法 安全
Java多线程编程实战:从入门到精通
【4月更文挑战第30天】本文介绍了Java多线程编程的基础,包括线程概念、创建线程(继承`Thread`或实现`Runnable`)、线程生命周期。还讨论了线程同步与锁(同步代码块、`ReentrantLock`)、线程间通信(等待/通知、并发集合)以及实战技巧,如使用线程池、线程安全设计模式和避免死锁。性能优化方面,建议减少锁粒度和使用非阻塞算法。理解这些概念和技术对于编写高效、可靠的多线程程序至关重要。
|
3天前
|
人工智能 安全 Java
Python 多线程编程实战:threading 模块的最佳实践
Python 多线程编程实战:threading 模块的最佳实践
131 5
|
3天前
|
监控 Java 调度
Java多线程实战-从零手搓一个简易线程池(四)线程池生命周期状态流转实现
Java多线程实战-从零手搓一个简易线程池(四)线程池生命周期状态流转实现
|
3天前
|
设计模式 Java
Java多线程实战-从零手搓一个简易线程池(三)线程工厂,核心线程与非核心线程逻辑实现
Java多线程实战-从零手搓一个简易线程池(三)线程工厂,核心线程与非核心线程逻辑实现
|
3天前
|
Java 测试技术
Java多线程实战-从零手搓一个简易线程池(二)线程池实现与拒绝策略接口定义
Java多线程实战-从零手搓一个简易线程池(二)线程池实现与拒绝策略接口定义
|
3天前
|
存储 安全 Java
Java多线程实战-从零手搓一个简易线程池(一)定义任务等待队列
Java多线程实战-从零手搓一个简易线程池(一)定义任务等待队列
|
3天前
|
消息中间件 缓存 NoSQL
Java多线程实战-CompletableFuture异步编程优化查询接口响应速度
Java多线程实战-CompletableFuture异步编程优化查询接口响应速度
|
3天前
|
存储 消息中间件 Java
Java多线程实战-异步操作日志记录解决方案(AOP+注解+多线程)
Java多线程实战-异步操作日志记录解决方案(AOP+注解+多线程)