深入浅出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的核心数和利用率问题，那么我们得到了最佳线程数计算的公式：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的时候可以成倍增加计算效率，但是很遗憾F不为0，同时随着你的请求数的增加，F的值也在增加，当这个串行率达到一定程度的时候，你的系统是没有任何效果的提升的。当F不变的时候，N增加，那么Speedup增加。但是当N->∞,那么整个公式就变成了1/F，也就是说当核数不断增大的时候，speedup是有上限的。
同样，对于1000ms/(CPU Time) * coreSize * cpuRatio我们不断的增加CoreSize或者说线程数的时候。我们的请求变多了，随之而来的就是大量的上下文切换、大量的GC、大量的锁征用，这些串行化的因素会大大增加F值，也会大大的增加CPU Time。假设我们的串行部分不变的话，增大核数，CPU不能得到充分的利用，利用率也会降低。所以，对于阿姆达尔定律而言，串行化的比率才是决定着是否能成倍增长效率的关键。也就是说最佳线程数也好，最大QPS也好，增加内核数量不一定能是系统指标有成倍的增长。更关键的是能改变自己的架构，减小串行的比率，让CPU更充分的利用，达到资源的最大利用率。

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

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