性能测试之响应时间、并发数、QPS、TPS
文章目录
- 前言
- 一、系统性能指标及评估方法
-
- 1.响应时间
-
- 1.1.呈现时间
- 1.2.网络传输时间
- 1.3.网络传输时间
- 1.4.合理的响应时间
- 2.并发用户数
- 3.系统吞吐量之QPS、TPS
-
- 3.1.QPS
- 3.2.TPS
- 3.3.QPS与TPS的区别
- 二、总结
前言
以下文章取至微信公众号：测试小哥进阶在性能测试系列的上一篇文章中：性能测试指标入门，已经简单介绍了在性能测试时不同群体的关注点及各个维度常见的性能指标。
因为 作者最近比较忙，所以本章将会在上一篇文章提到的七个维度中选取其中一个比较重要的维度 系统性能指标 作一个具体的介绍，想了解其它维度的指标评估方法诸位可以自己百度了解下。上一篇文章也简单提到了各维度的一个业内参考标准。
一、系统性能指标及评估方法
在上一篇文章说的系统性能指标有：响应时间、系统处理能力、吞吐量、并发用户数、错误率等。那么，在这些指标当中常关注的有哪些呢？
在这些指标当中，常关注的性能指标有：响应时间、并发数、QPS、TPS、错误率。下面具体介绍一下这些指标的评估方法。
1.响应时间
对用户来说可以对吞吐量（QPS、TPS）、并发用户数这些毫不关心，但响应时间及系统稳定性却是用户感受系统性能的最直观体现。从用户角度来说，系统性能就是系统对用户操作的响应时间。说得更简单一点，对用户来说，当用户点击一个按钮或一条链接，从用户单击开始到系统把本次操作的结果以用户能察觉的方式展示出来，在这过程所消耗的时间就是用户对软件性能的直观印象。
那么，这个时间是怎么评估出来的呢，可以用一个公式表示：
响应时间=网络传输时间（请求）+服务器处理时间（一层或是多层）+网络传输时间（响应）+页面前段解析时间
更具体来说： 响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间
1.1.呈现时间
呈现时间主要是指前端的响应时间，这部分时间主要取决于客户端而非服务端。当然，它还和承载它的操作系统以及电脑硬件（CPU、内存等）有关。
1.2.网络传输时间
千万不要忽视数据传输时间。试想一下，如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。
你的带宽是多少？有没有考虑网络延迟？ 互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。
这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，也有特殊的性能测试需要在互联网中时行。它们重点不是求用户的最大的并发量。
1.3.网络传输时间
系统得到请求后对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间，因为前面的呈现时间和数据传输时间都我们不可控制的，用户使用的电脑及浏览器千差万别，用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短。
如果我们对系统的的处理进行分析和讲解的话，它会是一个非常庞大与复杂的过程。语言、语言框架、中间件，数据库、系统架构以及服务器系统。现在的测试工具都屏蔽呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，也不会将服务器的每个响应都向客户端呈现。
对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。
1.4.合理的响应时间
我要访问百度首页，发出了一个请求，百度开始给我返回页面数据，当搜索框与搜索按钮都已经返回到页面上了，但那个图标还在发送中。我不认为这个响应是完整的。必须把页面上的所有信息都返回给我才是完整的，我要的也是所有结果返回给我的时间。这种情况更符合“响应时间”的定义。
某系统有一个信息查询功能，当我输入某条件查询时，可能要查询几百万条数据，如果数据库，要查询所有的数据并把所有的数据全部完整的返回给我。可能服务器要查询很久，而我的电脑全部接收这些数据也可能只直接挂掉。那么服务器可能只查询100条数据并把数据返回给我，当我点击“下一页”时，服务器再次查询并将第二页的数据返回给我。这种情况更符合“系统响应时间”的定义。
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”的没有绝对的。
在互联网行业对于用户响应时间，有一个普遍的标准：2/5/10秒原则。也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
这里我们还要考虑一个使用频率的因素。如果一个功能，一个月才用上一次，并且要求返回的结果也并非实时的，那么即便慢一些，对于用户来讲，也是可接受的。
比如一个税务报账系统，该系统的用户每月使用一次，一次花费3小时进行数据的录入。当用户单击“提交”按钮后，即使系统在10分钟后才给出“处理成功”的消息，我们也觉得是可以接受的。
因此，在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。
2.并发用户数
并发用户指的是系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。
在上一篇文章中说过并发用户、注册用户、在线用户是有很大差别的，并发用户一定会对服务器产生压力，而在线用户只是 ”挂” 在系统上，对服务器不产生压力，注册用户一般指的是数据库中存在的用户，即所有用户。并发用户的用户最大特征是会和服务器产生交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。
那么，对于测试系统来说，该怎么评估用户数呢？一般来说，可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，而并发用户数可以取其中8%至15%的比例基数。例如在1个小时内，使用系统的在线用户数为10万，那么取8%至15%（即8000至1.5万）作为并发用户数就可以了。
在网上也流行另一种并发用户数的评估计算方式。
假设：
- 登录系统的用户数量（n），可以理解为平均每天访问用户数
- 用户从登录系统到退出系统的时间间隔（L），可以理解为一天内用户从登录到退出系统的时间间隔
- 被考察的时间长度（T），可以理解为一天内有多长时间有用户访问系统
那么利用经验公式估算系统的平均并发用户数和峰值数据结果如下，其中√代表根号：
- 平均并发用户数为：C = n*L/T
- 并发用户数峰值: C‘ = C + 3*√C
拿一个网上经常举例的例子：
当然了，对于没有做过性能测试的系统来说，如果没有历史数据作参考，建议通过实际的一个项目情况由业务或相关部门进行评估。
3.系统吞吐量之QPS、TPS
系统吞吐量指单位时间内系统处理用户的请求数。从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量，从网络角度看，吞吐量可以用：字节/秒来衡量。
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力。以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示主要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
3.1.QPS
在上一篇文章提到了QPS，全名 Queries Per Second，表示“每秒查询率”，是一台服务器每秒能够响应的查询次数。具体说，QPS = req/sec = 请求数/秒。比如执行了select操作，相应的QPS就会增加，它代表的是服务器性能最大吞吐能力。
那么，计算QPS的常用公式又是怎么样的呢？具体如下：
- QPS（TPS）= 并发数/平均响应时间
另外，关于峰值QPS计算方式，一般也可参照2/8原则：
- 每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
- 公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
假如：每天300w PV 的在单台机器上，这台机器需要多少QPS？用公式可得出：(3000000 * 0.8) / (86400 * 0.2)=139 (QPS)
3.2.TPS
在上一篇文章中提到过TPS，TPS的全名是 Transactions Per Second，指每秒处理的事务数量。一个事务是指一个客户机向服务器发送请求然后服务器做出回应的过程。
关于TPS的评估方式，对于已有系统来说：可选取高峰时刻，在一定时间内（如3-10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍作为峰值的TPS。例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000-5000。
当然了，对于没有做过性能测试的系统来说，如果没有历史数据作参考，建议通过实际的一个项目情况由业务或相关部门进行评估。
3.3.QPS与TPS的区别
QPS与TPS对于刚接触的人来说是容易搞混淆的，那他们之间到底有什么区别和联系呢？
个人觉得，QPS基本类似于TPS。不同的是，对于一个页面的一次访问，会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就会计入“QPS”之中。所以，如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS=QPS。
例：假如访问一个 index 页面会请求服务器三次，一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“TPS”，三个“QPS”。
对于衡量单个接口服务的处理能力，一般采用QPS比较多；如果衡量事务业务场景的处理能力一般采用TPS。说到这里，在Jmeter聚合报告中，Throughput是用来衡量吞吐量，通常是用TPS来表示。
二、总结
一个系统处理性能能力通常由QPS、TPS、并发数决定的，每个系统这几个值都有一个相对极限值。在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等其它消耗导致系统性能下降。
影响系统响应时间由CPU运算、IO、外部系统响应等因素组成。一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等紧密关联，单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
最后，在给各位总结下及给出一些个人的小建议：
- 系统的性能一般由TPS决定，跟并发用户数没有太大的直接关系
- 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整
- 建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压
- 一般情况下，大型系统（业务量大、机器多）做压力测试，10000～50000个用户并发，中小型系统做压力测试，5000个用户并发比较常见
- 通过系统的监控工具，发现系统的性能瓶颈，通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等，而缓存系统容易发生瓶颈的地方是内存，储存型系统则是I/O
到此，性能测试理论性的知识就总结到这。计划后面还会在该系列出三篇文章，分别会围绕测试方案、测试计划、测试报告。不定期更新，该系列后面的文章可能更新时间间隔会久点，作者会把重心放在公众号其它栏目或专辑上。诸位大佬觉得不错可以分享关注哦~