关于系统性能测试中吞吐量的信息

本篇文章给大家谈谈系统性能测试中吞吐量，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享系统性能测试中吞吐量的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、关于吞吐量的计算
• 2、性能测试报告中吞吐量的秘密
• 3、系统吞吐量是什么意思？

关于吞吐量的计算

吞吐量计算公式。
我们在压测工具制作中，一直存在一个争议——吞吐量的计算。
在性能测试中，吞吐量的计算有两种常见的公式。
公式1：吞吐量=并发数/平均响应时间。
公式2：吞吐量=请求总数/总时长。
公式1、2大家应该都接触过，虽然看上去不一样，其实理论上都是ok的。首先我们可以从C=nL/T推导，并发=请求总数*平均响应时间/总时长。
并发/平均响应时间=请求总数/总时长。
公式1=公式2，然后我们构建三组模型进一步论证，一共有4个线程，同时发了4笔请求，其中3笔耗时1s，一笔耗时2s，整个过程一共耗时2s。

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

性能测试报告中吞吐量是一个非常重要的指标系统性能测试中吞吐量，该指标描述了被测系统在 一秒钟 内能够处理的 请求/交易数目 。吞吐量有时候也叫做每秒事务处理数（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之间增加比响应时间大几个数量级的思考时间，然后通过增加虚拟用户数目的方式来测试被测系统的吞吐量，尽量减少测试工具本身可能会对测试结果产生的不利影响。否则可能会得出“无法解释”的吞吐量报告。

系统吞吐量是什么意思？

吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。吞吐量与带宽的区分：吞吐量和带宽是很容易搞混的一个词，两者的单位都是Mbps。先来看两者对应的英语，吞吐量：throughput；带宽：Maxnetbitrate。当讨论通信链路的带宽时，一般是指链路上每秒所能传送的比特数，它取决于链路时钟速率和信道编码在计算机网络中又称为线速。可以说以太网的带宽是10Mbps。但是需要区分链路上的可用带宽（带宽）与实际链路中每秒所能传送的比特数（吞吐量）。通常更倾向于用“吞吐量”一词来表示一个系统的测试性能。这样，因为实现受各种低效率因素的影响，所以由一段带宽为10Mbps的链路连接的一对节点可能只达到2Mbps的吞吐量。这样就意味着，一个主机上的应用能够以2Mbps的速度向另外的一个主机发送数据。 关于系统性能测试中吞吐量和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统性能测试中吞吐量的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、系统性能测试中吞吐量的信息别忘了在本站进行查找喔。