系统吞吐量、QPS、并发数、响应时间，以及提高吞吐量的思路

一．系统吞度量要素：

吞吐量是指系统在单位时间内处理请求的数量

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  一般取平均响应时间

（很多人经常会把并发数和TPS理解混淆）

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间  

并发数 = QPS*平均响应时间

举个例子：

银行窗口业务，窗口数量为10个窗口，平均每个人办理业务的时候为2分钟。可以用下面的方法计算。

并发数=10个窗口

平均响应时间为 = 2分钟

吞吐量 = 10/2 =5个每分钟

真实的系统吞吐量：

如果一个系统接口在 4核8G的机器上跑

给接口分配4个线程，并发执行 ： 并发数= 4

平均响应时间是 100ms

QPS=4/0.1=40

提高吞吐量：

1. 并发数的优化：4个CPU

       接口处理可能包括：CPU处理 20ms、 本地IO 30ms、网络IO  50ms

       可以在本地IO和网络IO阻塞时，并发处理其他线程：每个线程任务真正占用CPU的时间是 20ms

       那么，单个CPU100ms可以并发 5个线程，4个CPU*5=20个并发数

       忽略线程切换的耗时：100ms 单个CPU可以并发5个线程，每个线程占用CPU时间片20ms，等都执行完了，各自的IO也已经返回数据，再分别耗时1ms(忽略) 去接收IO返回

2. 响应时间优化：100ms优化到50ms

     本地IO+网络IO 增加响应的二级三级缓存，并优化网络通信，可能可以提审一倍以上的性能，比如30ms

     加上CPU处理耗时的20ms= 50ms        

QPS=并发数20/响应时间50ms = 20/0.05 = 400QPS

        一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降。

1. 并发数不变：QPS不断增加，QPS超过最大吞吐量后，会有大量请求等待，平均响应时间急剧下降

2. QPS不变：增加并发数，会导致CPU并发线程过多，线上上下文切换频繁，内存消耗增加，从而使平均响应时间下降

二．如何提高系统QPS？

由前面的公式：QPS（TPS）= 并发数/平均响应时间 可以看出，要提高qps,我们必须做2个方面努力

2.1增加并发数

1.比如增加tomcat并发的线程数，开喝服务器性能匹配的线程数，可以更多满足服务请求。

2.增加数据库的连接数，预建立合适数量的TCP连接数

3.后端服务尽量无状态话，可以更好支持横向扩容，满足更大流量要求

4.调用链路上的各个系统和服务尽量不要单点，要从头到尾都是能力对等的，不能让其中某一点成为瓶颈。
5.RPC调用的尽量使用线程池，预先建立合适的连接数。

2.2减少平均响应时间

1.请求尽量越前结束，越好，这样压力就不要穿透到后面的系统上，可以在各个层上加上缓存

2.流量消峰。放行适当的流量，处理不了的请求直接返回错误或者其他提示。和水坝道理很类似

3.减少调用链

4.优化程序

5.减少网络开销，适当使用长连接

6.优化数据库，建立索引

最后，要优化的地方还有很多，上面只是列举常见一些要注意的地方

优化的指导原则就是增加并发数 和减少平均响应时间

下面的内容整理引用其他博客，用于参考

三．系统吞吐量评估：

我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。

通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

通常的技术方法：

        1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）

        2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。

A)淘宝

淘宝流量图：

淘宝的TPS和PV之间的关系通常为  最高TPS：PV大约为 1 : 11*3600 （相当于按最高TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）

B) B2B中文站

B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。

在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。

无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：
TPS=U_concurrent / (T_response+T_think)。

并发数、QPS、平均响应时间三者之间关系

   上图横坐标是并发用户数。绿线是CPU使用率；紫线是吞吐量，即QPS；蓝线是时延。
    开始，系统只有一个用户，CPU工作肯定是不饱合的。一方面该服务器可能有多个cpu，但是只处理单个进程，另一方面，在处理一个进程中，有些阶段可能是IO阶段，这个时候会造成CPU等待，但是有没有其他请 求进程可以被处理）。随着并发用户数的增加，CPU利用率上升，QPS相应也增加（公式为QPS=并发用户数/平均响应时间。）

随着并发用户数的增加，平均响应时间也在增加，而且平均响应时间的增加是一个指数增加曲线。而当并发数增加到很大时，每秒钟都会有很多请求需要处理，会造成进程（线程）频繁切换，反正真正用于处理请求的时间变少，每秒能够处 理的请求数反而变少，同时用户的请求等待时间也会变大，甚至超过用户的心理底线。

软件性能测试的基本概念和计算公式

一、软件性能的关注点

对一个软件做性能测试时需要关注那些性能呢？

我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次，我们站在管理员的角度考虑需要关注的性能点。

1、 响应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争

参考：

如何提高系统的吞吐量（QPS/TPS）