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

转载自：

深入浅出QPS、RT和最佳线程数
阿姆达尔定律

什么是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的核心数和利用率问题，那么我们得到了最佳线程数计算的公式：
(（CPU Time + CPU Wait Time）/ 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呈线性增长。但是很遗憾，现实中不是这样的…首先先看一下阿姆达尔定律：
阿姆达尔定律给出了任务在固定负载的情况下，随着系统资源的提升，执行速度的理论上限。以计算机科学家Gene Amdahl命名。

其中
Slatency: 整个任务的提速比。
s: 部分任务得益于系统资源升级带来的提速比。
p: 这部分任务执行时间占整个任务执行时间的百分比（系统资源提升前）。

从上可以得到：

以上公式说明了通过资源升级来给任务加速的加速比上限，而且和提速的幅度无关，理论加速比总是受限于不能加速的任务的比例。

阿姆达尔的定律常用于并行计算中，用来估计多处理器情况下的理论加速比。例如，如果有个程序在单核下需要执行20个小时，并且不能被并行处理的部分占1个小时的执行时间，剩余的19个小时(p=0,95)的任务可以并行化，那么不管有多少核心来并行处理这个程序，最小执行时间不可能小于一个小时。由此得到，理论加速比的上限是20倍（1/(1-p) = 20）。因此，并行计算只和少数的核心和极度可并行化的程序相关。

同样，对于1000ms/(CPU Time) * coreSize * cpuRatio我们不断的增加CoreSize或者说线程数的时候。我们的请求变多了，随之而来的就是大量的上下文切换、大量的GC、大量的锁征用，这些会增加不可并行部分的总时间，也会大大的增加CPU Time。假设我们的串行部分不变的话，增大核数，CPU不能得到充分的利用，利用率也会降低。所以，对于阿姆达尔定律而言，不可并行部分的比率才是决定着是否能成倍增长效率的关键。也就是说最佳线程数也好，最大QPS也好，增加内核数量不一定能是系统指标有成倍的增长。更关键的是能改变自己的架构，减小串行的比率，让CPU更充分的利用，达到资源的最大利用率。

再看一下最佳线程数和最大QPS

通过上面一些例子，我们发现当线程数增加的时候，线程的上下文切换会增加，GC Time会增加。这也就导致CPU time 增加，QPS减小，RT也会随着增大。这显然不是我们希望的，我们希望的是在核数一定的情况下找到某个点，使系统的QPS最大，RT相对较小。所以我们需要不断的压测，调整线程池，找到这个QPS的峰值，并且使CPU的利用率达到100%,这样才是系统的最大QPS和最佳线程数。