这里只提供最常用的Dubbo服务调优点简要说明,旨在用更小的成本,获得更多性能收益。
这里的“成本”是综合性的,包括 时间、硬件、技术学习等。即,此指南追求“实用性”。
“最常用”、“简要”也意味着这不是一份全面的Dubbo调优指南。
但是对于绝大多数微服务而言,足矣。再继续调优,很可能就是涉及具体的业务逻辑流程。
threadpool 表示线程池类型。其值可以是 “fixed” 或 “cached”。默认值:fixed
fixed 表示线程池启动时就创建了固定大小的线程数,不做任何伸缩。
其创建原理与java内置的 Executors.newFixedThreadPool() 相同。
相关dubbo代码:com.alibaba.dubbo.common.threadpool.support.fixed.FixedThreadPool
cached 表示线程池是可伸缩的,线程空闲时间达到阈值时会被回收。这个阈值默认是1分钟。
其创建原理与java内置的 Executors.newCachedThreadPool() 相同。
相关dubbo代码:com.alibaba.dubbo.common.threadpool.support.cached.CachedThreadPool
threads 表示线程池最大线程数。
对于 fixed 类型的线程池,如果未配置该属性,则使用默认值 200,即固定200个线程。
对于 cached 类型的线程池,如果未配置该属性,则使用默认值 Integer.MAX_VALUE (2147483647)。
对于刚开始性能调优的dubbo服务来说,“默认fixed线程池+200线程”的配置往往是最先需要优化的点。
一旦并发请求数超过200,就会出现异常“Thread pool is EXHAUSTED”。
另,线程池的类型选择也应遵循具体业务场景。
如果请求频繁,cached 意义也不会很大,因为线程根本没有空闲后被回收的机会。
如果请求不频繁,fixed 类型的线程池中大量线程空闲在那也浪费资源。
dispatcher 表示协议的消息派发模式。dubbo协议默认值为 “all”。(dubbo服务默认采用dubbo协议)
一般可以选“message”,即只有请求响应消息派发到线程池,其它连接断开事件、心跳等消息,直接在IO线程上执行。
Dubbo服务支持在服务端和客户端配置服务调用超时时间。它们的默认值都是1000毫秒。
如果服务端和客户端都配置了 timeout,则以客户端的配置为准。
通常,除非客户端业务规则明确规定超时时间,不会在客户端配置 timeout。所以服务端的 timeout 配置很关键。
timeout 与具体业务和服务部署方式与环境的关系很大,需要根据实际测试数据调整。
对于负载稍高的服务,默认的1000毫秒超时时间,确实容易引发 TimeoutException。
如果服务传输的数据量较大,调用耗时也会非常可观。