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

一、性能测试中的TPS

二、基于目标的性能测试

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的设置有更深入的了解，在做性能测试时做到目标清晰，有章可循。

网站题目：基于目标TPS的性能测试，如何通过手动设置场景进行测试？
路径分享：http://www.shufengxianlan.com/qtweb/news14/479314.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联