1.性能测试中的TPS众所周知，TPS（TransactionsPerSecond的缩写）是性能测试中的一个重要指标，用来衡量被测系统的性能。TPS高说明系统处理速度快，TPS值低说明系统处理速度慢，可能需要进行性能优化。通常TPS只是反映测试结果，与测试结果一样多。但是很多时候我们需要提前指定TPS的目标值，通过测试验证是否达到了目标值，那么如何测试呢？2.基于目标的性能测试Loadrunner在新建测试场景时，可以选择手动场景或者基于目标的场景，如下图：目标可以选择tps，hitspersecond等type：设置target后，直接运行即可。执行后可以看到目标是否达到。这个过程是自动完成的，内部如何实现对我们来说完全是一个黑盒子。本文介绍如何通过手动设置场景完成基于TPS目标的测试，重点介绍目标TPS是如何计算的。3.测试场景设置我们还是选择手动设置loadrunner测试场景。通常会有单一交易场景测试和混合交易场景测试。下面举两个例子：无论是单一场景还是混合场景，目标TPS的计算原理都是一样的。4.场景公式在上面的场景例子中，我们需要关注4个字段：虚拟用户数（简称vu），目标tpsPacingThinktime，所有场景的thinktime为0秒。步调和思考时间在概念上既相关又不同。Thinktime比较常用，也比较容易理解。这里就不介绍了，下面重点说说节奏。Pacing是loadrunner中的一个设置选项，如下图所示：Pacing是指动作迭代的延迟时间。选项1意味着迭代不会延迟。选项2是在上一次迭代结束后需要多长时间才能开始下一次迭代。从迭代开始到结束的时间间隔。方案三其实就是设置每次迭代的预期完成时间。例如设置pacing为60秒，表示action的事务需要在60秒内执行。如果动作执行了4秒，那么接下来的56秒会等到60秒120秒后开始下一次迭代；如果动作执行了120秒，下一次迭代将在执行结束后立即开始。我们可以称前者为“包含”，因为执行时间小于pacing时间，后者称为“不包含”，因为执行时间大于pacing时间。只要“包含”动作的平均响应时间，就可以达到目标TPS。理解上面的原理很重要，下面看一个例子。假设如下测试结果：当vu为1时，只要动作响应时间小于等于2秒pacing，理论上tps应该是0.5。也就是说，只要动作响应时间在pacing以内，无论响应时间多快，tps都不会增加。当vu为10时，动作的响应时间仍然不到2秒，在pacing范围内，算是“遏制”了，达到了5TPS。同样，当vu为20时，action的响应时间仍然不到2秒，在pacing范围内，算是“contained”，达到了10TPS。在动作的响应时间超过pacing之前，tps和vu之间存在正比关系。当vu为100时，动作响应时间为10秒，不在pacing2秒的范围内，“不包含”，无法达到理论的50tps。通过上面的分析，我们可以得到vu、pacing和targettps之间的关系，即在action的响应时间超过pacing之前，targettps=vu/pacing通过这个公式可以更准确的测试系统的tps，通过大量的测试实验，结果与公式一致。目标tps是根据需求得到的，设置一个pacing就可以知道要测试多少vu。降低pacing和增加vu都可以提高目标tps。推荐的方法是先设置pacing，再设置vu。pacing的值基本上是10秒，或者10秒的倍数。步调确定后，将不再更改。想要提高目标tps，只能提高vu。五、总结本文介绍了基于目标tps的性能测试方法。希望通过这篇文章，让大家对tps的设置有更深入的了解，在做性能测试的时候目标明确，有章可循。
