Web-Server有个配置,工作线程数。
Service一般也有个配置,工作线程数。
经验丰富的架构师,懂得如何配置这些参数,使得系统的性能达到最优:有些业务设置为CPU核数的2倍,有些业务设置为CPU核数的8倍,有些业务设置为CPU核数的32倍。
“线程数”的设置依据,是本文要讨论的问题。
工作线程数是不是设置的越大越好?
答案显然是否定的:
调用sleep()函数的时候,线程是否一直占用CPU?
不占用,休眠时会把CPU让出来,给其他需要CPU资源的线程使用。
不止sleep,一些阻塞调用,例如网络编程中的:
都会让出CPU资源。
单核CPU,设置多线程有意义么?
单核CPU,设置多线程能否提高并发性能?
即使是单核,使用多线程也是有意义的,大多数情况也能提高并发:
了解常见的服务线程模型,有助于理解服务并发的原理,一般来说互联网常见的服务线程模型有两种:
第一种,IO线程与工作线程通过队列解耦类模型。
如上图,大部分Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型:
这个线程模型应用很广,符合大部分场景,这个线程模型的特点是,工作线程内部是同步阻塞执行任务的,因此可以通过增加Worker线程数来增加并发能力,今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。
第二种,纯异步线程模型。
没有阻塞,这种线程模型只需要设置很少的线程数就能够做到很高的吞吐量,该模型的缺点是:
however,这个模型不是今天讨论的重点。
了解工作线程的工作模式,对量化分析线程数的设置非常有帮助:
上图是一个典型的工作线程的处理过程,从开始处理start到结束处理end,该任务的处理共有7个步骤:
(1)从工作队列里拿出任务,进行一些本地初始化计算,例如http协议分析、参数解析、参数校验等;
(2)访问cache拿一些数据;
(3)拿到cache里的数据后,再进行一些本地计算,这些计算和业务逻辑相关;
(4)通过RPC调用下游service再拿一些数据,或者让下游service去处理一些相关的任务;
(5)RPC调用结束后,再进行一些本地计算,怎么计算和业务逻辑相关;
(6)访问DB进行一些数据操作;
(7)操作完数据库之后做一些收尾工作,同样这些收尾工作也是本地计算,和业务逻辑相关;
分析整个处理的时间轴,会发现:
通过上面的分析,Worker线程在执行的过程中:
通过量化分析,例如打日志进行统计,可以统计出整个Worker线程执行过程中这两部分时间的比例,例如:
得到的结果是,这个线程计算和等待的时间是1:1,即有50%的时间在计算(占用CPU),50%的时间在等待(不占用CPU):
当当当当!!!
结论来了:
N核服务器,通过执行业务的单线程分析出本地计算时间为x,等待时间为y,则工作线程数(线程池线程数)设置为 N*(x+y)/x,能让CPU的利用率最大化。
一般来说,非CPU密集型的业务(加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务),瓶颈都在后端数据库访问或者RPC调用,本地CPU计算的时间很少,所以设置几十或者几百个工作线程是能够提升吞吐量的。