Jmeter-线程组和循环控制器在性能方面的差异
我对JMeter是新手。这里有一件事让我困惑
我正在测试两个使用Jmeter计算性能数字的场景
- 具有1个线程组集且循环计数设置为50，并且具有一个https采样器。
- 具有循环计数仅为1的1个线程组，但使用循环计数设置为50的循环控制器。在本例中，我的https采样器位于循环计数中。
在这两种情况下，https采样器都运行了50次，但我注意到了很多性能差异。
For 1 - 100 ms ( Average of 50 calls)
For 2 - 30 ms ( Average of 50 calls)
问题是为什么我会看到这种差异。理想情况下，两个场景应该给出相同的性能数。另外，为了添加到我的Jmeter设置中，我将“use keep alive”设置为off，并且在Jmeter.properties中将https.use.cached.ssl.context设置为false。
共有1个答案
对于在线程组级别上定义50个循环的场景，您的ramp-up设置是什么？根据文件
上升周期告诉JMeter“上升”到所选线程的全部数量需要多长时间。如果使用10个线程，并且上升周期为100秒，那么JMeter将需要100秒来启动并运行所有10个线程。每个线程将在前一个线程开始后10（100/10）秒开始。如果有30个线程和120秒的上升周期，那么每个连续的线程将延迟4秒
默认情况下，ramp-up是1。如果要为线程组和循环控制器寻找相同的行为，则需要将其设置为0。
展望未来，以JMeter的速度发送请求并不能称为现实生活中的负载场景。真正的用户不会在这个或那个endpoint上下功夫，他们在做下一个动作之前需要一些时间来“思考”。这个“思考时间”可以用常量定时器来模拟。然而，设置所需负载的更聪明的方法是使用恒定吞吐量计时器
-
人们到底是如何从JMeter发送请求的。给定这个配置是否意味着JMeter将创建200个线程，并在循环中发送并发请求20次。我假设这意味着每个线程阻塞，直到上一个请求完成，并发送下一个请求，并且每个线程执行该过程20次。 假设我有一个示例请求a,num threads=2,loop count=5,我设想工作流如下所示 在时间t0线程1->向目标服务器发送一个 在时间t0线程2->向标记服务器发送
-
问题内容： 以下两个循环之间的性能差异（如果有）是什么？ 和 问题答案： 版本1.5中引入的for-each循环通过完全隐藏迭代器或index变量，消除了混乱和出错的机会。结果成语同样适用于集合和数组： 当你看到冒号（:)时，将其读为“ in”。因此，上面的循环读为“对于元素中的每个元素e”。请注意，即使对于数组，使用for-each循环也不会降低性能。实际上，在某些情况下，它可能只比普通的for
-
在循环中，我们不断终止条件，并在每一次传递中检查这些条件。 我见过2种检查方法 1.或
-
在我的网站上，我有两个商人行动：搜索和浏览。一次搜索通常会触发三次浏览。 我有一个JMeter测试，它使用商家和商家id号的CSV文件，当按比例运行这个测试时，我希望我站点上的所有商家都被使用。 我在JMeter中进行了映射，如下所示： 循环控制器 HTTP采样器（Search/Search/${merchant_name}） CSV数据集配置（商家名称） 循环控制器 HTTP采样器（Browse
-
while 关键字可以用作当型循环（当条件满足时循环）。 让我们用 while 循环写一个不怎么出名的 FizzBuzz 程序。 fn main() { // 计数器变量 let mut n = 1; // 当 `n` 小于 101 时进入循环操作 while n < 101 { if n % 15 == 0 { printl
-
Rust 提供了 loop 关键字来实现一个无限循环。 可以使用 break 语可以在任何时刻退出一个循环，另外可用 continue 跳过迭代的剩余部分并重新开始 一轮循环。 fn main() { let mut count = 0u32; println!("Let's count until infinity!"); // 无限循环 loop {