深入浅出QPS、RT和最佳线程数.docxVIP

深化浅出QPS、RT和最佳线程数 2021-10-15 什么是QPS QPS是每秒钟处理完恳求的次数。这里的恳求不是指一个查询或者数据库查询，是包括一个业务规律的整个流程，也就是说每秒钟响应的恳求次数。 什么是响应时间 响应时间即RT，处理一次恳求所需要的平均处理时间。对于RT，客户端和服务端是大不相同的，由于恳求从客户端到服务端，需要经过广域网，所以客户端RT往往远大于服务端RT，同时客户端的RT往往打算着用户的真实体验，服务端RT往往是评估我们系统好坏的一个关键因素。 最佳线程数的困扰 在开发过程中，我们肯定面临过很多的线程数量的配置问题，这种问题往往让人摸不到头脑，往往都是拍脑袋给出一个线程池的数量，但这可能恰恰是不靠谱的，过小的话会导致恳求RT极具添加，过大也一样RT也会上升。所以对于最佳线程数的评估往往比较麻烦。 QPS和RT的关系： 单线程场景： 假设我们的服务端只要一个线程，那么全部的恳求都是串行执行，我们可以很简约的算出系统的QPS，也就是：QPS = 1000ms/RT。假设一个RT过程中CPU计算的时间为49ms，CPU Wait Time 为200ms，那么QPS就为1000/49+200 = 4.01。 多线程场景 我们接下来把服务端的线程数提升到2，那么整个系统的QPS则为：2 *（1000/49+200）=8.02。可见QPS随着线程的添加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公式也说得通，但是往往现实并非如此，后面会聊这个问题。 最佳线程数？ 从上面单线程场景来看，CPU Wait time为200ms,你可以理解为CPU这段时间什么都没做，是空闲的，明显我们没把CPU利用起来，这时候我们需要启多个线程去响应恳求，把这部分利用起来，那么启动多少个线程呢？我们可以估算一下 空闲时间200ms，我们要把这部分时间转换为CPU Time,那么就是200+49/49 = 5.08个，不考虑上下文切换的话，约等于5个线程。同时还要考虑CPU的核心数和利用率问题，那么我们得到了最佳线程数计算的公式：RT/CPU Time * coreSize * cupRatio 最大QPS？ 得到了最大的线程数和QPS的计算方式： QPS = Thread num * 单线程QPS = （CPU Time + CPU Wait Time）/CPU Time * coreSize * CupRatio * (1000ms/(CPU Time + CPU Wait Time)) = 1000ms/(CPU Time) * coreSize * cpuRatio 所以打算一个系统最大的QPS的因素是CPU Time、CoreSize和CPU利用率。看似添加CPU核数（或者说线程数）可以成倍的添加系统QPS，但实际上添加线程数的同时也添加了很大的系统负荷，更多的上下文切换，QPS和最大的QPS是有偏差的。 CPU Time CPU Wait Time CPU 利用率 CPU Time就是一次恳求中，实际用到计算资源。CPU Time的消耗是全流程的，涉及到恳求到应用服务器，再从应用服务器前往的全过程。实际上这取决于你的计算的简单度。 CPU Wait Time是一次恳求过程中对于IO的操作，CPU这段时间可以理解为空闲的，那么此时要尽量利用这些空闲时间，也就是添加线程数。 CPU 利用率是业务系统利用到CPU的比率，由于往往一个系统上会有一些其他的线程，这些线程会和CPU竞争计算资源，那么此时留给业务的计算资源比例就会下降，典型的像，GC线程的GC过程、锁的竞争过程都是消耗CPU的过程。甚至一些IO的瓶颈，也会导致CPU利用率下降(CPU都在Wait IO，利用率当然不高)。 添加CPU核数对QPS的提升 从上面的公式我们可以看出，假设CPU Time和CPU 利用率不变，添加CPU的核数能使QPS呈线性增长。但是很圆满，现实中不是这样的首先先看一下阿姆达尔定律： 阿姆达尔定律.png 阿姆达尔定律是一个很有意思的定律，简约的我们可以理解为，程序中可并行代码的比例打算你添加处理器（总核心数）所能带来的速度提升的上限。换句话说就是串行化对于你系统吞吐量的影响。举个栗子: 1.坐车问题： 假设你想从望京去顺义，那么你智能坐着一辆车过去，虽然现在有十辆车，你也不能提升十倍的效率，这里F就是1，由于全部的动作都需要串行，speedup就等于1，效率没提升，虽然你有九辆车。 2.写代码问题： 假设你现在开发一个系统，你可以把全部的任务均分下去，假设10个人帮你开发，那么F就为0，N为10，那么speedup等于10，也就是说你提升了10倍的速率。 这里的N就是我们的核数。在F为0的时候可以成倍添加计算效率