转：http://www.10tiao.com/html/439/201512/423511225/1.html
性能分析的基本概念：QPS/TPS
很多人不会做性能分析或者调优的关键点在于：不知道怎么做性能分析。很多人觉得性能调优是一件很难的事情，无从下手。其实这些都有方法，只要掌握了一定的方法和技巧，这不是一件很复杂的事情。
两个最朴实的概念:QPS/TPS
QPS:Query Per Second
TPS:Transactions Per Second
这两个概念起源于数据库系统，是衡量数据库性能的重要指标。
数据库的操作可以分为增、删、改、查这几类。
QPS用在对于查询类的性能统计，这类查询基本不需要在事务块中进行限制，不用在独立的事务块中保持独立；对于非查询类，通常是需要在事务块中进行数据的ACID保证，所以对事务或者资源具有独占性，性能情况会受制于独占资源的消耗。`
在应用系统中，QPS和TPS的概念经常已经混淆。
但是其基本语义未变：可以泛指在特定周期内的处理能力。
影响QPS/TPS的主要因数
先举例几个压测是经常遇到的几个场景
场景1：**线程池和QPS的关系**
某一天一个开发做压力测试。在一台4核机器上测试。先是用10个用户压测,测出QPS为60;
再用20个用户压测,测试QPS 为100;
最后一次用30个用户压测,测试QPS为100,怎么30个用户的QPS 就不增加了呢?
于是他增加了线程池的线程数量由10调整到30,再次使用30个用户进行压测,居然QPS还是200左右。
他索性又把线程池的线程数量增加到50,再次30个用户压测,奇怪了!怎么QPS还是200左右,没有增加呢!
请问:为什么增加线程池,QPS先是上升,再次增加就不上升了呢?
场景2：**什么是瓶颈资源**
某一天这个开发做压⼒测试。在一台4核机器上测试。
这次是一个新的业务,此业务中含有数据库事务,对单条记录操作的时候会上锁。
于是他开始测试,用10个用户压测,测试QPS为40左右;
于是他用20个用户压测,居然还是40左右;30个用户,依然如此。
好吧,既然不想,老招数,加⼤大线程池,由10上升到20,再到30依然没有。
绝望了,性能实验室,有台8核机器,来吧,试试。。。。 QPS居然还是40左右。。。
请问:为什么增加线程池,甚⾄至增加CPU核数,QPS没有增加呢?
场景3：**响应时间和QPS的关系**
某⼀天这个开发接到一个任务。又是烦人的外围配合改造,改造是这样的:某个系统做了性能优化,老的服务调用需要50ms,⽽现在只需要20ms。
这个开发一想,这不是很好嘛,可以减少业务处理时间,那请求的响应时间自然就变少了,那QPS不是就增加了么?
想的倒是很美。。。于是配合改造,发布上线,到线上一看,XX的,响应时间确实少了,但是怎么QPS没有增加呢?
请问:为什么响应时间变少,QPS没有增加,响应时间和QPS的关系是什么呢?
通过上面的几个场景，没有经验的人可能会比较迷惑。
传统QPS公式可以写成：QPS = 1000ms/响应时间 * CPU核数，这个是多数人的理解：
当机器由4核换成8核的时候，QPS一定是会增加的，因为可以用于处理的CPU更多了
当响应时间变少的时候，分母变小了，所以QPS增加了。
但是通过上面的例子可以看出，实验结果不是想得这样。（当然如果你怀疑列举的场景，可以自己做下实验）
那么问题来了：**是什么影响了QPS，QPS和CPU、线程、响应时间、并发量之间的关系是什么？**
关系图.png
深入剖析响应时间
多数人不能正确的去分析QPS，绝大部分的原因是不知道响应时间具体消耗在什么资源上，所以做不了正确的分析和判断。
所以自己先从响应时间上去解释，下列的响应时间模型是我自己提炼的，未必是完全符合理论或者所有人的理解。
V1版本的响应时间模型：响应时间=请求传输时间+服务端处理时间+响应传输时间
这个版本的服务端处理时间很笼统。
image.png
V2版本的响应时间模型：****响应时间=请求传输时间+内部服务处理时间+外部服务处理时间+响应传输时间
这个版本的服务端服务端处理时间拆分成两部分
image.png
V3版本的响应时间模型：****响应时间=请求传输时间+服务内部CPU运算+服务内部IO时间+外部服务处理时间+响应传输时间
这个版本的服务端服务端处理时间进一步拆分，拆分为不同的资源消耗
image.png
V4版本的响应时间模型：****响应时间=请求传输时间+服务内部CPU运算+服务内部IO时间+内部共享资源时间+外部服务处理时间+响应传输时间
image.png
通过上面的分解，对响应时间有个分解。最后把响应时间的组成提炼为如下内容
image.png
理解最优线程数
最优线程数的定义：使用最少的线程保持资源最大化的使用。
常有两种情况：
当线程数较少的时候,压力情况下,可能造成线程资源不足,请求需要等待线程释放后,才能处理。
当线程数量较多的时候,线程自身也是需要消耗内存资源,导致资源的浪费;同时,线程较多的时候对于线程的调度和争用也会影响性能。
对于最优线程数常常有一些经验或者理论上的值：
N+1:保证CPU在一定的阻塞情况下,也有可以运行的线程进⾏调度,进 而保证CPU的运⾏和利用
N-1:减少线程和线程调度间的争用和调度
这些理论值常常是没用的！！！
理解响应时间、最优线程数、CPU之间的关系
下面以一个例子来说明这几个的关系：假设一个请求的响应时间是100ms，1个CPU，1个线程的情况下推演。
image.png
一个请求的执行快照如上图。处理过程大概为：请求1绑定到线程1，线程1绑定到cpu1，cpu1上执行100ms完成本次请求；
线程1继续处理后续请求，比如请求2、请求3。
但是通过上面响应时间模型可以得知，一个请求的响应时间不一定全部都是CPU耗时组成，那么可能运行的快照如下图：
image.png
当一个请求只有20ms在CPU上运行，其余的80ms都在等待外围的响应，那么可以得出：线程1会在等待外围80ms是阻塞；cpu1会在线程1阻塞时空闲。
那么为了让CPU满转，资源使用最大化，那么需要使用几个线程呢？
image.png
通过上图可以看出，当有线程阻塞，不断的补充线程进行执行，就可以让CPU满转。大概可以得出：最优线程数=线程总时间/线程CPU执行时间 * CPU核数。
似乎分析到这里，应该就快清晰的知道答案了，但是我们离的还远。下面进一步分析
理解瓶颈资源：多资源情况下的线程调度分析
假设这样的一个场景：
假设一个请求的服务器端处理时间为10ms。其中cpu执行5ms,4个CPU;数据库操作时间5ms,应用总共有2个可用连接
那么最后线程数是多少？如果按照上一步计算：最优线程数=线程总时间/线程CPU执行时间 * CPU核数=10ms/5ms * 4 = 8
上面的计算正确吗？为了解释多资源情况下的线程调度，使用如下几个快照分析。
把CPU时间划分为5ms为一个时间段区域
1、第1个5ms快照的运行情况如下：同时有4个线程在4个CPU上运行，cpu处于满转。
image.png
2、第2个5ms快照的运行情况如下：同时有4个线程在4个CPU上运行，cpu处于满转；2个线程处理数据库操作。
image.png
3、第3个5ms快照的运行情况如下：同时有4个线程在2个CPU上运行，cpu处于满转；2个线程处理数据库操作；其他被阻塞
image.png
4、第4个5ms快照的运行情况如下：同时有4个线程在2个CPU上运行，cpu处于满转；2个线程处理数据库操作；其他被阻塞。
image.png
5、第5个5ms快照的运行情况如下：同时有4个线程在2个CPU上运行，cpu处于满转；2个线程处理数据库操作；其他被阻塞。
image.png
通过上面的内容可以看出，最优线程数不仅仅取决于CPU核数，当在多资源的情况下时：取决于资源短板。
这个类似于水桶原理：
image.png
说了这么多，是不是感觉没啥鸟用！
通过上面的推导，简单明了的告诉几个理论上的公式
最优线程公式
最优线程数量=线程总时间/瓶颈资源时间 * 瓶颈资源并行数
一个线程1S可以处理的请求数
1000/线程总时间
QPS公式1
QPS =最优线程数量* 1000/线程总时间
QPS公式2
QPS=1000/瓶颈资源时间 * 瓶颈资源并⾏行数
通过公式2可以看出：影响QPS的关键因素受限于瓶颈资源，所以大部分的性能优化问题都是在解决：如何找出瓶颈资源，如何优化代码对瓶颈资源的消耗。