性能测试混合场景设计

在线用户如果没有进行实际操作那么他最多将消耗一个连接线程，而应用CPU并不会有什么资源消耗。100个用户平均每个花费10秒下一个订单和10个用户每1秒钟下一个订单对应用带来的压力是一样的。所以，在场景中能用最少的并发用户来模拟真实的请求是最经济的选择方式。

一般情况下，为了方便我们统计TPS，建议一个脚本只包含一个完整的交易，不要把多个交易放到一个脚本中。因为，不同的交易其响应时间会不同，响应时间较长的交易会成为“瓶颈”。另外，我们设计测试场景时需要考虑不同交易的占比，如果多个交易存在同一个脚本里，场景的设计就无法实现。

那么是什么因素决定一个场景要并发用户的多少呢？主要是被测交易的响应时间和场景的目标TPS。交易响应时间的快慢是决定并发用户数量的主要因素，例如一个应用的某个交易响应时间是50ms，如果要实现100TPS的目标，那么只需5个并发用户即可达到（目标TPS*交易平均响应时间=并发用户量）。如果响应时间是100ms，那么实现同样的TPS需要的并发用户就会多一倍。

如何设计监控

例如混合容量场景如果执行30分钟，那么采集频率可以为每5秒钟采集一次，共采集360次。但是，考虑到监控要提前启动，所以采集次数可以适当增加一些，这样可以确保整个监控区间大于场景执行区间，也就同时监控到了资源使用在压力发起前后的变化情况。对于执行时间较长的场景，我们就要适当调整采集间隔和采集次数，例如对于一个执行12小时的稳定性场景，我们可以每50秒采集一次，共采集1000次。

单交易负载的场景具体该如何设计与执行呢？如果你想找出每个交易的最优TPS，可以从5个并发用户开始，执行几分钟后再增加5个用户，直到应用CPU使用率超过70%为止。场景的延时设置为0，场景执行前需开启相关监控。该场景用于获取单交易在并发情况下的响应时间与TPS，发现交易本身是否存在并发问题，应用是否会出现错误和异常，响应时间相对单交易基准是否有明显的提高，资源使用率是否在合理的承受范围之内等等。

测试模型到底该如何确定呢？通过需求调研获得。下面介绍的两点是我们常用的调研方式：

1，对于还未上线运营的新系统，我们一般会让应用的产品经理或负责人给出一个预估的比例；但是这个预估需要我们进行评估，不是随意的。对于一个以提供下单交易为主的应用，通常下单交易是占整个模型的较大比例，如果需求方提出的模型是查询比例较高，那么我们就有理由怀疑该模型的合理性。对于这种情况，我们建议选择几个常见的典型的模型来配合需求模型进行场景设计。2，对于已上线运营的应用，我们一般会分析实际的交易数据来确定交易比例，这样会更加精准。例如一个应用对用户提供下单、查询、退款三个交易，我们通过DBA在线查询某日的交易数据总量为200000笔，其中交易下单160000笔、查询38000笔，退款2000笔，由此我们算出各交易的比例是80%、19%、1%，那么这个比例就是我们的测试模型。

多交易混合负载

多交易混合负载的目的是为了找到应用的最优TPS，即应用CPU资源消耗在70%左右时的TPS（此时需确保数据库等其他被调用资源不成为瓶颈）。

按照测试模型中的交易比例及目标TPS，对每个交易分配不同的并发用户数量，设置不同的延时，同时进行加压，通过多个子场景的不断尝试最终测试出应用能够达到的最优TPS。这个场景比较复杂，一般需要经过多次的测试与调整才能到达测试模型的比例要求。经过单交易负载测试之后我们已经获取了每个交易的平均响应时间，那么由此值我们便可以设置我们的混合负载场景。假设，我们应用的测试指标TPS为100，单交易负载测试获取的各交易响应时间如下：下单0.4秒，查询0.2秒，退款0.5秒，那么要达到100TPS的压力，该如何设置场景？

计算每个交易的TPS
下单TPS=100*80%=80，查询TPS=100*19%=19，退款TPS=100*1%=1

确定每个交易的并发用户
目标TPS、响应时间、并发用户之间有这样一个关系：目标TPS=并发用户/响应时间

如果一个交易响应时间是0.2秒，那一个用户时的TPS就是1/0.2=5。
在咱们这个实例中每个交易的并发用户计算如下：

下单交易并发用户数量 = 80*0.4 = 32
查询交易并发用户数量 = 19*0.2 = 3.8
退款交易并发用户数量 = 1*0.5 = 0.5

大家看到了，这里出现了非整数的情况，怎么办？对于这种情况我们要进行整数化处理。即我们一般取大于并最接近当前数的整数，3.8我们按4，0.5我们按1。整数化后对应的响应时间也应该发生变化，否则就无法实现目标TPS。整数化再次计算实际的响应时间：

查询交易调整后的响应时间=4/19=0.21
退款交易调整后的响应时间=1/1=1

于是场景设置如下，下单交易并发用户32个延时设置为0秒，查询交易并发用户4个延时设置0.01秒，退款交易并发用户1个延时设置0.5秒，场景运行时间10分钟以上。但是这个场景运行结果可能并不会完全符合我们的预期，因为并发用户相比单交易负载场景已经增加了很多，交易的响应时间很可能会出现明显的延长。比如下单交易的实际响应时间可能会延长到0.6秒，那么实际的TPS将明显下降。如果出现这种情况该如何处理呢？我们推荐使用区间型延时设置，将这个“区间时间”设置的比实际交易响应时间大一些，根据这个时间再计算对应的并发用户量。另外，建议大家建一个excel的表格，用于计算延时和并发用户的值，效果见下表2。

表2中的列“延时设置”的值是使用公式自动计算出来的，公式为“=并发用户单元格编号/（目标TPS单元格编号*交易占比单元格编号）”。建立这个表之后我们只需手动修改两个列的值就可以方便地计算出每个场景下的每个交易的延时，这两个列就是“平均响应时间”和“并发用户数”。平均响应时间随着并发用户的增加必然会相应地增长，所以在表2中每个场景的平均响应时间数据都是上个场景的执行结果。这样我们每执行完成一个场景，然后就把响应时间的数据填写到下个场景中，然后再修改并发用户数量，并确保延时设置大于平均响应时间即可，如果在测试执行过程中出现平均响应时间大于延时设置时间时需要停止场景重新计算。

综上所述，多交易混合负载场景并不是一个场景，而是一系列混合场景的集合。还以上例来说，目标100TPS时我们分析监控结果发现系统各项资源利用率都不是太高，这说明应用还能够承受更大的压力。这就需要我们继续加大压力进行测试。我们可能的场景是150TPS、200TPS等等。那么如何确定我们的压力梯度呢？这就要看系统资源到底使用了多少，如果100TPS时发现系统各项资源使用率在50%左右，我们就可以估计应用的最优TPS应该能够达到150，那么我们下一个场景就是要按150TPS的目标压力去发压，相关的并发用户和延时根据上表进行调整即可。如果不能实现150TPS的压力，那么我们就要减少目标TPS再进行发压，直到测试获取到应用的最优TPS。

大并发

该类场景的目的是考察系统在大并发的情况下是否存在问题，是否有报错，是否有用户失败等。大并发一般要设置一个延时，用于到达最优并发时的TPS。那么，大并发时的用户到底设置多少，这个延时要设置多久，依据是什么呢？一般我们设置的并发用户数量是最优并发的5至10倍，而延时要通过计算得到。这里还是举例说明，有一个应用，测试得到的最大TPS为200，对应的并发用户为20，那么我们可以设置两个大并发场景，即100并发用户和200并发用户。100并发时的延时设置为100/200TPS=0.5秒，200并发时的延时设置为200/200TPS=1秒，这个延时为区间型的延时。

通常，在进行大并发测试时获得的TPS结果要比最大TPS低很多，因为在大并发时系统很有可能出现某些资源不够用，线程很可能会出现严重的阻塞等等。

如何考量大并发测试获得的测试结果是否符合预期，或者说大并发测试通过的标准是什么？这个也没有固定的标准可循，通常我们认为只要符合如下两方面的要求即可认为测试通过。

最大并发用户量是否能达到最大TPS时的5倍；

测试结果的TPS是否达到测试指标的要求；

需要说明的是这里的大并发和应用的最优并发与最大并发并不是一回事，二者并不相同。

————————————————
版权声明：本文为CSDN博主「陈秋歌」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/chenqiuge1984/article/details/80129298