实时警报通知：微信告警通知的重要性解析
1537
2023-02-23
性能测试中吞吐量（性能测试吞吐量指标）
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈性能测试中吞吐量，以及性能测试吞吐量指标对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享性能测试中吞吐量的知识，其中也会对性能测试吞吐量指标进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
吞吐量的计算方式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之间增加比响应时间大几个数量级的思考时间，然后通过增加虚拟用户数目的方式来测试被测系统的吞吐量，尽量减少测试工具本身可能会对测试结果产生的不利影响。否则可能会得出“无法解释”的吞吐量报告。
例如：一个水龙头在24小时内流出10吨水；它的吞吐量是10吨水；
10个水龙头在1秒内共计流出0.1吨水；它有吞吐量是0.1吨水；
但并不能说1个水龙头的出水能力比10个水龙头出水能力强，所以，就需要加单位时间了，看谁1秒内的出水量大，这就是吞吐率。
吞吐率： 指单位时间内处理的客户请求数量。通常情况下，用“字节数/秒”来衡量；也可以“请求数/秒”“页面数/秒”来衡量，其本质都是在网络上传输的数据，而数据的单位就是字节数；从业务角度来讲，吞吐率还可以用“业务数/小时或天”，“访问人数/小时或天”，“页面访问量/小时或天”来衡量。
TPS（Transaction Per second): 每秒钟系统能处理的事务数量；
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行性能瓶颈定位时有着非常关键的作用。
Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
所以，一个网站优化的目的是，最大限度的利用好服务器硬件资源提升资源利用率，减少用户请求的响应时间，提高系统吞吐量，提高系统并发数。
吞吐量： 一段时间内应用系统处理用户的请求数（以下介绍指单位时间内，也可以理解为吞吐率），这个定义考察点一般是系统本身因素；当然也可以用单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数，这个定义的考察点既有系统本身因素也有网络，外设等因素，也可以理解为除客户端以外的测试环境及被测系统。
并发用户数： 指同一时间点对业务功能同时操作的用户数，可以分为两种： 一种 是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这时业务功能一般指同一类型的业务； 另外一种 并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的，这时业务功能可能不是同一类型的业务。
并发数 = 吞吐量
一般来说，在系统的设计范围之内，吞吐量随系统的并发用户数的增加呈现增加趋势，也就是说你客户端来多少请求数系统吃（处理）多少请求数；当超出这个范围时有两种情况，一种是系统只能处理这么多，超过这个数系统不接收了，最后随着并发用户数的增多吞吐量是一个水平的直线；
还有一种情况是不管来多少系统都接收最后导致系统吞吐量下降甚至系统崩溃。并发用户数是客户端单位时间内对服务器端施加的压力，具体能不能接受并处理要看被测系统的吞吐量，而吞吐量是被测系统单位时间内处理的请求数或者说单位时间内处理的字节数；一个着重于客户端的操作即测试手段，一个着重于应用系统的处理能力即查看对象；（上面的讨论没有考虑两者的单位，如一个用户同时有多个请求情况）
两者的计算公式如下：
其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。（该公式针对一般被测系统，特殊不做讨论）
吞吐量计算：当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间，其实通过这个公式就能看出吞吐量与并发用户数之间的关系了（这里的VU就是我们用工具模拟的并发用户数）。
参考：
https://www.cnblogs.com/cynchanpin/p/7365859.html
https://www.sohu.com/a/256477206_100224606
https://www.cnblogs.com/111testing/p/11402799.html 关于性能测试中吞吐量和性能测试吞吐量指标的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 性能测试中吞吐量的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于性能测试吞吐量指标、性能测试中吞吐量的信息别忘了在本站进行查找喔。
本文目录一览：
性能测试报告中吞吐量的秘密
性能测试报告中吞吐量是一个非常重要的指标，该指标描述了被测系统在 一秒钟 内能够处理的 请求/交易数目 。吞吐量有时候也叫做每秒事务处理数（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的速度向另外的一个主机发送数据。
性能指标-吞吐量 Throughput
吞吐量： 指在网络上传输的数据量的总和；它反映地是服务器承受压力的能力；例如：一个水龙头在24小时内流出10吨水；它的吞吐量是10吨水；
10个水龙头在1秒内共计流出0.1吨水；它有吞吐量是0.1吨水；
但并不能说1个水龙头的出水能力比10个水龙头出水能力强，所以，就需要加单位时间了，看谁1秒内的出水量大，这就是吞吐率。
吞吐率： 指单位时间内处理的客户请求数量。通常情况下，用“字节数/秒”来衡量；也可以“请求数/秒”“页面数/秒”来衡量，其本质都是在网络上传输的数据，而数据的单位就是字节数；从业务角度来讲，吞吐率还可以用“业务数/小时或天”，“访问人数/小时或天”，“页面访问量/小时或天”来衡量。
TPS（Transaction Per second): 每秒钟系统能处理的事务数量；
性能压测时，并发压力增加，系统响应时间和吞吐量如何变化
性能测试
性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段。
做性能优化的时候，一方面提高性能指标，另一方面要考虑到提高用户的主观感受（可以利用异步操作）。架构师训练营不介绍主观视角
性能测试指标
其他常用指标：
吞吐量 = ( 1000 / 响应时间 ms) × 并发数
吞吐量 Throughput 的讨论需要有时间单位，一般采用 Bytes/Second、Pages/Second 和 Request/Second 等单位。
不同并发用户数场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也不一样。
比如 100 个并发用户，每用户每隔 1 秒发出一个 Request 和 1000 个并发用户，每隔 10 秒发出一个 Request，两个场景有相同的吞吐量 100 Request/Second，但是两个场景所占用的资源不一样，性能拐点也肯定不一样。
性能测试方法
究竟部署多少台服务器（资源）比较合适？是架构师需要考虑的一个决策，找到性能、价格的平衡点。架构师要清醒的知道，决策的依据到底是什么，可能的代价是什么，是否能够承担这个责任……
Performance Testing Methodology, Quest Soft, 2005
在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。
——《02丨性能综述：TPS和响应时间之间是什么关系？》 性能测试实战30讲
通常从两个层面定义性能场景的需求指标：业务指标和技术指标。
所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。
Jmeter之性能测试指标介绍
常用的网站性能测试指标有：TPS、吞吐量、并发数、响应时间、性能计数器等。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行性能瓶颈定位时有着非常关键的作用。
Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
所以，一个网站优化的目的是，最大限度的利用好服务器硬件资源提升资源利用率，减少用户请求的响应时间，提高系统吞吐量，提高系统并发数。
吞吐量： 一段时间内应用系统处理用户的请求数（以下介绍指单位时间内，也可以理解为吞吐率），这个定义考察点一般是系统本身因素；当然也可以用单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数，这个定义的考察点既有系统本身因素也有网络，外设等因素，也可以理解为除客户端以外的测试环境及被测系统。
并发用户数： 指同一时间点对业务功能同时操作的用户数，可以分为两种： 一种 是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这时业务功能一般指同一类型的业务； 另外一种 并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的，这时业务功能可能不是同一类型的业务。
并发数 = 吞吐量
一般来说，在系统的设计范围之内，吞吐量随系统的并发用户数的增加呈现增加趋势，也就是说你客户端来多少请求数系统吃（处理）多少请求数；当超出这个范围时有两种情况，一种是系统只能处理这么多，超过这个数系统不接收了，最后随着并发用户数的增多吞吐量是一个水平的直线；
还有一种情况是不管来多少系统都接收最后导致系统吞吐量下降甚至系统崩溃。并发用户数是客户端单位时间内对服务器端施加的压力，具体能不能接受并处理要看被测系统的吞吐量，而吞吐量是被测系统单位时间内处理的请求数或者说单位时间内处理的字节数；一个着重于客户端的操作即测试手段，一个着重于应用系统的处理能力即查看对象；（上面的讨论没有考虑两者的单位，如一个用户同时有多个请求情况）
两者的计算公式如下：
其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。（该公式针对一般被测系统，特殊不做讨论）
吞吐量计算：当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间，其实通过这个公式就能看出吞吐量与并发用户数之间的关系了（这里的VU就是我们用工具模拟的并发用户数）。
参考：
https://www.cnblogs.com/cynchanpin/p/7365859.html
https://www.sohu.com/a/256477206_100224606
https://www.cnblogs.com/111testing/p/11402799.html 关于性能测试中吞吐量和性能测试吞吐量指标的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 性能测试中吞吐量的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于性能测试吞吐量指标、性能测试中吞吐量的信息别忘了在本站进行查找喔。
相关文章
发表评论
暂时没有评论，来抢沙发吧~