基于目标TPS的性能测试,如何通过手动设置场景进行测试?

上一篇 / 下一篇  2022-05-13 16:55:00 / 个人分类:性能测试

一.性能测试中的TPS

众所周知,TPS(即Transactions Per Second的缩写)是性能测试中的一项重要指标,用于衡量被测系统的性能,TPS高则说明系统处理速度快,TPS低则说明系统处理速度慢,可能需要做性能优化。通常TPS只是反应测试结果,测试出多少就是多少,然而很多时候我们需要事先指定TPS的目标值,通过测试来验证目标值是否达,那么该如何进行测试呢?加我VX:atstudy-js 回复“测试”,进入 自动化测试学习交流群~~

二.基于目标的性能测试

Loadrunner在新建测试场景时,就可以选择手动场景还是基于目标的场景,如下图所示:

目标类型可以选择tps、hits per second等:

设置好目标后,直接运行就可以了,执行完成可以看到目标是否达到了。这个过程都是自动完成的,其内部是如何实现的,对于我们来说完全是个黑盒子。本文介绍的是如何通过手动设置场景来完成基于TPS目标的测试,重点介绍目标TPS是如何计算出来的。

三.测试场景的设置

我们还是选择手动设置loadrunner的测试场景,通常会有单交易场景测试和混合交易场景测试,下面是2个示例:


无论是单场景还是混合场景,目标TPS的计算原理都是一样的。

四.场景公式

在上面的场景例子中,我们需要重点关注4个字段:

·虚拟用户数量(简称vu)

·目标tps

·Pacing

·Thinktime

所有场景的 thinktime 都是 0 秒,pacing 和 thinktime 在概念上有联系也有区别。

Thinktime 比较常用,易理解,这里不多介绍,下面重点说一下 pacing。Pacing 是 loadrunner

中的一个设置选项,如下图所示:

Pacing 指 action 迭代的延迟时间,选项一是迭代不延迟,选项二是在上一次迭代结束后多长时间开始下一次迭代,选项三是每次迭代从开始到结束的时间间隔。

选项三实际上是设置每次迭代的期望完成时间,例如设置pacing为60秒,表示action这个事务要求在60秒内执行完成,如果action执行了4秒,那么后面的56秒会等待,直到60秒后再开始下一次迭代;如果action执行了120秒,那么执行结束后会立即开始下一次迭代。前者我们可以称之为“包含住”,因为执行时间小于pacing时间,后者称为“未包含住”,因为执行时间大于pacing时间。只要action的平均响应时间“包含住”了,目标TPS就可以达到。

理解上面的原理很重要,下面我们看一个例子。

假设有如下的测试结果:

vu为1时action的响应时间只要小于等于2秒pacing,理论tps应该都是0.5,换句话说只要action响应时间在pacing内,响应时间再快,tps不会增加。

vu为 10 时,action的响应时间仍小于2秒,在pacing范围内,“包含住”了,达到5个TPS。同理,vu为20时,action的响应时间仍小于2秒,在pacing范围内,“包含住”了,达到10 个TPS。在action的响应时间未超出pacing之前,tps和vu存在正比关系。

vu为100时,action响应时间为10秒,不在pacing2秒范围内,“未包含住”,理论的50个tps就不可能达到了。

通过以上分析,我们可以得出vu、pacing、目标tps三者之间的关系,即:

在action的响应时间未超出pacing之前,目标tps=vu/pacing通过该公式,可以较精确的测试出系统的tps,通过大量的测试试验,结果也是和公式吻合的。

目标tps根据需求得到,设置一个pacing就知道需要测试多少vu。减少pacing和增加vu都可以增加目标tps。建议的做法是先设定pacing,然后再设置vu,pacing的取值基本都是10秒,或者是10秒的倍数。pacing确定后就不再改变,要想增加目标tps,只能调大vu。

五.总结

本文介绍了基于目标tps的性能测试方法,希望通过本文,能让大家对tps的设置有更深入的了解,在做性能测试时做到目标清晰,有章可循。

添加微信:atstudy-js  或者扫描下方二维码,备注“博客”邀请你进入Python自动化测试学习交流群~


TAG:

 

评分:0

我来说两句

Open Toolbar