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

本文探讨了Dubbo服务提供者中io线程池和业务线程池的区别,如何通过dispatcher参数调整优化,针对不同场景下的简单和复杂业务逻辑进行压力测试。重点讲解了线程池满时的策略选择,以及如何通过实例和压测结果分析提高服务性能。
最低0.47元/天 解锁文章
713

被折叠的 条评论
为什么被折叠?



