性能测试报告中吞吐量的秘密

本文版权归XMeter所有，欢迎转载，转载请注明出处。

性能测试报告中吞吐量是一个非常重要的指标，该指标描述了被测系统在一秒钟内能够处理的请求/交易数目。吞吐量有时候也叫做每秒事务处理数（Transaction Per Second，简称TPS），TPS的粒度更大一些，落实到具体的测试脚本上，就是将一系列的请求组合成一笔交易，以这笔交易作为衡量吞吐量的最小粒度。但是吞吐量这个指标的数据有时候会“捣乱”，如果只是看其中的一些表面意义的话，解读出来的数据就会有很大的问题，甚至会误导对被测系统能力的判断。那XMeter君就来带领大家看一下吞吐量这个指标后面的秘密。

吞吐量的计算方式1：假设累积一段时间t秒的请求或者交易数目为c，计算吞吐量为：c/t = x（个/秒）。比如在一分钟内，被测系统能够处理30笔交易，那么该系统的吞吐量为30/60（秒）=0.5，我们称该系统的吞吐量为0.5。同理，如果在5秒钟内，被测系统能够处理6个请求，那么吞吐量为6/5=1.2。

吞吐量的计算方式2：如果针对单个用户单笔交易的处理时间为x秒，那么每秒能够处理的交易数为1/x。假设现有y个用户，假设系统能轻松处理这y个用户的请求，那么该系统的针对该交易的吞吐量为: y/x。根据此种计算方法，如果单笔交易时间是0.5秒，那么一秒钟能处理2笔交易，如果系统能够同时服务10个用户，那么该系统的吞吐量为20.

这两种计算方式都没有问题，正常情况下应该可以互相印证。但是我们现在来研究一下下面的这个JMeter测试脚本，该脚本非常简单，它的任务是判断每个虚拟用户里循环执行的次数，只有在偶数次的时候才会执行Debug Sampler里的请求。

- 计数器：用于计数，得到当前运行的次数。具体设置如下图所示，启动值为1，递增为1，最后把值存入iterationNum变量中

- 如果（If）控制器：用于判断是否执行Debug Sampler，逻辑如下，如果变量iterationNum是偶数的话Debug Sampler才会被执行。

Debug Sampler是JMeter提供的内置Sampler，主要任务用于打印JMeter的虚拟用户中的变量等值，用于调试脚本之用。该Sampler主要是从内存中读取并打印变量的值，没有网络等费时的操作，一般来说其执行速度会非常之快，由此可见如果执行上述测试脚本的时候，其吞吐量会非常的高。如下图所示，是该脚本在XMeter上运行的结果截屏。可以看到该Sampler的平均响应时间非常小，大概为0.01毫秒，按照我们脚本的逻辑，由于没有思考时间，而且该Sampler的执行速度非常快，所以基本上可以认为该脚本大概每隔百分之一毫秒就可以完成一次请求，那么在一秒钟内一个用户应该可以完成100000个请求，所以吞吐量应该大约为10万。可是读者看一下下面的测试报告会发现吞吐量才242！那么问题出在哪儿了？

我们来看一下，XMeter君得出10万的吞吐量是基于我们之前列出的第二种计算方式，这种计算方式有一个假设前提：测试工具能够毫无延迟的情况下在完成了一次请求的时候，马上发出第二次请求。回到我们的脚本，意味着第一次请求完成需要0.01毫秒，然后0.01毫秒之后JMete马上就可以发出第二次请求。我们可以看一下脚本里用了“如果（If）控制器”，该控制器里有一个表达式用于判断是否要执行Debug Sampler，问题主要就出在这个控制器上了：该控制器拖慢了JMeter执行脚本的速度，根据XMeter测试报告中实际的吞吐量的值，我们大概可以估算出该控制器的执行所需时间约为1000/242=4毫秒（Debug Sampler的时间量级与控制器的执行基本可以忽略不计了）。那有的同学可能就会说，这个JMeter也太差了吧，怎么会造成这么大的误差！不过你要是这么想可真冤枉了JMeter了，如果没有这些控制器的话，你怎么写出模拟各种业务场景的测试脚本呢？既想马儿不吃草，又想马儿跑得好，哪有这么两全其美的事情呢？

当然了，其实JMeter对于“如果（If）控制器”还是有优化的方法的，缺省的情况下该控制器用的是JavaScript的表达式运算方式，你想想每次执行的时候先JMeter需要把JavaScript引擎先起来，然后执行一下得到表达式的结果，这得花多少时间啊。在使用“如果（If）控制器”的时候可以用JMeter提供的jexl3函数来提高脚本执行效率，如下图所示，表达式变成了${__jexl3(${iterationNum} % 2 == 0)} 之后，同样的测试脚本吞吐量变成了1813，但是离100000的理论值还是差的很远，但是毕竟比刚才的测试结果已经提升了7倍多。

话说到这儿，读者是不是对JMeter生成的测试结果感到很不可靠？差不多的脚本，这个吞吐量的值也差的太远了。工具在实现的时候对功能的复杂性、易用性和准确性等方面都会综合考虑，我们这里举的例子比较极端，如果真正理解了背后的原理，是可以解决的。造成这个问题的根源在于：Sampler的响应时间太短，而脚本中别的元素执行时间远远超过了正常Sampler的执行时间，从而导致这么大的误差，了解了该问题，我们就可以在编写测试脚本的时候避免类似的问题。因此用户在写脚本的时候如果发现了被测服务的响应时间比较短，那么最好通过在Sampler之间增加比响应时间大几个数量级的思考时间，然后通过增加虚拟用户数目的方式来测试被测系统的吞吐量，尽量减少测试工具本身可能会对测试结果产生的不利影响。否则可能会得出“无法解释”的吞吐量报告。