性能测试进阶：提前设定TPS如何做测试？
性能测试进阶：提前设定TPS如何做测试？
性能测试中的TPS
众所周知，TPS（即Transactions Per Second的缩写）是性能测试中的一项重要指标，用于衡量被测系统的性能。TPS值越高，说明系统处理速度越快；TPS值越低，则说明系统处理速度慢，可能需要进行性能优化。
通常情况下，TPS只是反映测试结果，测试出多少就是多少。然而，在很多场景下，我们需要事先指定TPS的目标值，通过测试来验证目标值是否达成。那么，该如何进行这样的测试呢？
基于目标的性能测试
Loadrunner在新建测试场景时，可以选择手动场景或基于目标的场景。在基于目标的场景中，可以设置TPS、hits per second等目标类型。设置好目标后，直接运行测试即可，执行完成后可以看到目标是否达到。
这个过程都是自动完成的，其内部实现对于用户来说完全是个黑盒子。本文将介绍如何通过手动设置场景来完成基于TPS目标的测试，重点介绍目标TPS是如何计算出来的。
测试场景的设置
我们选择手动设置Loadrunner的测试场景。通常会有单交易场景测试和混合交易场景测试。无论是单场景还是混合场景，目标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的设置有更深入的了解，在做性能测试时做到目标清晰，有章可循。