响应时间好/低，但吞吐量也显示低Jmeter结果
- 用户：100
- 平均Res:2.4秒
- 吞吐量：10/分钟
- 错误%:0
通过关闭所有监听器，在非GUI模式下运行测试。Jmeter实例和应用服务器的CPU、内存利用率良好。不超过30%的使用率。
共有1个答案
最有可能的是预处理器、后处理器或定时器，它们会降低脚本中的某个地方的执行速度。
前面提到的测试元素执行时间不包括在响应时间中，除非您配置了一个事务控制器，将这些元素添加到所有其子事务的总事务执行时间中。
您可以通过run-start no pauses菜单项在GUI模式下运行一次脚本，这应该会禁用“Hibernate”
-
我运行jmeter脚本将近一周，今天观察到一件有趣的事情。以下是场景： 概述：我正在逐渐增加应用程序的负载。在上一次测试中，我给应用程序加载了100个用户，今天我将加载增加到150个用户。 150名用户测试结果： > 与上次测试相比，请求的响应时间减少了。（这是个好兆头） 吞吐量急剧下降到上一次测试的一半，负载更少。 我的问题是： > 当我的许多请求失败时，我得到了好的响应时间吗？ 注：直到100
-
我为帖子的篇幅感到抱歉，但有很多事情可能会导致我的情况，我已经尝试将我根据其他帖子所做的所有设置更改包括在内。简言之，我的WCF服务似乎一次只能处理3到4个并发客户端请求。如果我将应用程序池最大工作进程数设置得更高（大约10个），或者将服务行为ConcurrencyMode设置为多个，那么吞吐量就会大大提高（快几倍）。然而，这些似乎是真正问题的解决办法，带来了他们自己的问题。是我错了，还是IIS应
-
我对193个示例运行了一个JMeter测试，平均响应时间为5915ms，Throghput为1.19832。 我只想知道它们到底有什么关系
-
我得到了以下结果，吞吐量没有变化，即使我增加了线程数。 场景#1： 线程数：10 加速期：60 吞吐量：5.8/s 平均值：4025 场景#2： 线程数：20 加速期：60 吞吐量：7.8/s 平均值：5098 场景#3： 线程数：40 加速期：60 吞吐量：6.8/s 平均： 4098 我的JMeter文件包含一个单一的ThreadGroup，其中包含一个GET。 当我执行对响应时间更快（小于3
-
在进行测试时，我需要从宣誓API中获取令牌，并在另一个成功完成的后续API中使用它。但是，当通过CLI生成HTML报告时，还会计算誓言API的响应时间和吞吐量，有没有一种方法可以忽略该请求？
-
汇总报告中最后一行显示的总吞吐量是否正确？我使用的是Jmeter 2.11 有人能帮我一下吗？