吞吐量值是否与JMeter中请求的响应时间有关？
我得到了以下结果，吞吐量没有变化，即使我增加了线程数。
场景#1：
线程数：10
加速期：60
吞吐量：5.8/s
平均值：4025
场景#2：
线程数：20
加速期：60
吞吐量：7.8/s
平均值：5098
场景#3：
线程数：40
加速期：60
吞吐量：6.8/s
平均： 4098
我的JMeter文件包含一个单一的ThreadGroup，其中包含一个GET。
当我执行对响应时间更快（小于300毫秒）的endpoit的请求时，我可以实现每秒超过50个请求的吞吐量。
你能看到这个瓶颈吗？
响应时间和吞吐量之间有关系吗？
共有2个答案
在理想情况下，如果线程数增加2倍，吞吐量也会增加同样的系数。
事实上，“理想”场景很难实现，所以它看起来像是应用程序中的瓶颈。查明瓶颈的过程通常如下：
>
一旦您确定了什么是饱和点，您就需要知道是什么阻止了您的应用程序提供更多的请求，原因可能是：
- 应用程序只是缺少资源（CPU、RAM、网络、磁盘等），请确保监视上述资源，这可以使用JMeter PerfMon插件来完成
正如JMeter用户手册所述：
吞吐量=（请求数）/（总时间）
现在假设您的测试只包含一个GET，那个么吞吐量将是请求的平均响应时间。
注意升级周期：60将开始创建超过1分钟的线程，因此它将增加总执行时间，您可以尝试将其减少到10或等于线程数。
但您可能有其他采样器/控制器/组件，可能会影响总时间。
在您的情况下，尤其是在场景3中，可能一些请求失败，那么您没有计算成功事务的吞吐量。
-
在进行测试时，我需要从宣誓API中获取令牌，并在另一个成功完成的后续API中使用它。但是，当通过CLI生成HTML报告时，还会计算誓言API的响应时间和吞吐量，有没有一种方法可以忽略该请求？
-
我对193个示例运行了一个JMeter测试，平均响应时间为5915ms，Throghput为1.19832。 我只想知道它们到底有什么关系
-
我已经使用作为jmeter插件提供的吞吐量整形仪创建了一个最大峰值负载为5000 rpm的概要文件。 当我添加“每秒事务数”作为侦听器以分析每秒请求时。它没有显示5000rpm的峰值负载。 每秒事务侦听器是否显示吞吐量成形仪生成请求的图，或针对任何目标服务器生成的请求的实际执行图。 如何确认请求的生成达到5000 rpm的最大峰值负载？目前，我正在使用http采样器生成请求。
-
用户：100 平均Res:2.4秒 吞吐量：10/分钟 错误%:0 通过关闭所有监听器，在非GUI模式下运行测试。Jmeter实例和应用服务器的CPU、内存利用率良好。不超过30%的使用率。
-
我运行jmeter脚本将近一周，今天观察到一件有趣的事情。以下是场景： 概述：我正在逐渐增加应用程序的负载。在上一次测试中，我给应用程序加载了100个用户，今天我将加载增加到150个用户。 150名用户测试结果： > 与上次测试相比，请求的响应时间减少了。（这是个好兆头） 吞吐量急剧下降到上一次测试的一半，负载更少。 我的问题是： > 当我的许多请求失败时，我得到了好的响应时间吗？ 注：直到100
-
在我的测试计划中，我有24个吞吐量控制器，它们的执行率不同，最小的是1%。10个不同的吞吐量控制器有1%的执行率。每个吞吐量控制器下面都有许多事务控制器。当我运行一个测试1小时时，在某些最小百分比吞吐量控制器下定义的采样器甚至不会执行一次。我已经确保所有24个吞吐量控制器的总数增加到100%。如何确保在所有吞吐量控制器上定义的所有采样器至少执行一次？ 对于吞吐量最少的控制器，我将其更改为“Tota