问题标签 [threadgroup]

我在 JMeter 5.4.1 中遇到了一个问题，我的线程组没有达到每秒指定的事务。

我在一个并行运行的 JMeter 测试中有两个线程组。每个线程组都进行一个 API 调用。第一个线程组有 300 个线程分配给它，并且有一个恒定的吞吐量计时器，目标吞吐量为每分钟 45,000 个样本，最终为每秒 750 个事务。第二个线程组有 100 个线程分配给它，并且有一个恒定的吞吐量计时器，目标吞吐量为每分钟 9,000 个样本，最终为每秒 150 个事务。

在运行了几次测试之后，两个线程组都没有达到它们的目标吞吐量。第一个线程组每秒处理大约 300 个事务，第二个线程组每秒处理大约 100 个事务。第一个线程组的平均响应时间为 5 ms，第二个线程组的平均响应时间为 8 ms。这让我相信测试时的服务保持良好，但 JMeter 机器却没有。

奇怪的是，在单个 JMeter 实例上并行运行这些线程组会导致每秒事务数减少。我们进行了一个实验，将两个线程组拆分为两个不同的 JMeter 实例，并在同一台机器上同时运行它们。这使我们能够达到正确的交易/秒。这让我相信机器可以跟上，但是当它在一个 JMeter 实例中运行这两个线程时，JMeter 有一些奇怪的地方。关于为什么会这样以及如何解决它的任何线索？

接下来的情况是：我需要使用 jmeter 运行性能测试。我已经设置了几个 Graphql 请求，对它们进行了测试，它们运行良好。接下来是流程的想法：

1. 用户使用 graphql 突变登录平台，并在响应标头中收到 accessToken，有效期为一小时。
2. 下一个 graphql 请求必须解析生成的令牌，并使用这个令牌执行下一个突变。
3. 这个想法是用 250k 个请求测试平台，这需要 1 个多小时，并且您可能理解 - 令牌已过期。

我在脚本中做了什么：

1. 我创建了 2 个线程组。首先，有一个 Flow is Control 动作元素，它设置为暂停持续时间 3600000 毫秒。这意味着它将每小时运行一次登录请求。
2. 我正在使用 JSON 提取器抓取令牌，并使用 BeanShell 后处理器通过以下命令对其进行打包：

props.put("accessToken", vars.get("accessToken"));

3. 第二个线程组有一个 Graphql 请求来执行对服务器的 250k 请求，并使用来自 HTTP 标头的令牌值： Bearer ${__P(accessToken)}

一切正常，接受这个事实，我不知道如何设置场景，在第二个线程组完成 250k 个请求之后，登录的线程组将完成其运行。我已经尝试将循环控制器添加到登录，设置为无限，但是一旦第二组完成 250k 请求 - 运行将不会完成，因为登录将每小时运行一次。

有任何想法吗？

我想使用终极线程组进行测试，并发 2100 个用户，并将计时器与模拟用户数同步到 100 组。

这里我想配置线程组10分钟。

我不确定如何在初始延迟、启动时间、保持负载和关闭时间之间分配它

我想为 50 个用户测试系统的行为。25 个用户必须执行操作 X，输入 A，25 个用户必须执行操作 Y，输入 B（用户 X 和 Y 在 CSV 文件中）。我希望 CSV 文件中的前 25 个用户执行操作 X，而后 25 个用户执行操作 Y。

这个问题是在接受高级开发人员角色的采访时提出的。因为我没有接触过 Java 多线程和并发。所以，我无法回答这个问题。

我们创建的每个线程都是 ThreadGroup 的一部分。那么我们如何创建一个没有 ThreadGroup 的线程呢？

以下代码给了我 NullPointerException。

此代码的最后一行给出 NullPointerException。

在 JMeter 测试计划中，我有 4 个线程组，它们将连续执行，但是某些变量从一个线程组到另一个线程组存在依赖性，因此，如果前一个线程组中的任何采样器失败，后续线程的执行团体应该停止。

测试计划：

每个线程组都是一个简单的线程组[不是setUp或tearDown线程组]

如何控制或决定 JMeter 中的线程组执行流程/顺序？

我正在使用 jMeter 作为我的测试脚本。我需要 3 个线程组，因为 3 个用户将登录并从 CSV 文件中读取 3 个不同的行。我的线程组不应连续或同时启动。他们应该在他们之间的一些延迟之后开始。

我在登录请求之前添加了流控制操作（用于延迟），但延迟无法正常工作，即，所有线程大部分时间同时启动。

任何人都可以为我的不同线程组中的登录操作之间的延迟建议我更好的选择吗？

我已按以下顺序添加了测试计划

截屏

如何将访问令牌从第一个线程组传递到第二个线程组？

我编写了以下计算着色器来使用一些复杂的内核来模糊图像：

我编写了这个着色器来优化一些模糊操作，类似于128x128 图片上的高斯模糊，我在iPhone XR上的 Xcode 帧调试器中对其进行测试和分析发现：

从循环中的线程组内存“gCache”加载比直接采样纹理（即）慢得多（着色器需要30%的总时间来加载 gCache，但如果我直接更改为只需要< 5%的总时间采样纹理到采样纹理）t_f123.sample(s_f123, _3.xy, uint(round(_3.z)), level(0.0)

至于性能计数器，纹理读取实际上正在下降，但奇怪的是主内存带宽几乎没有改变。

我猜是因为使用了过多的线程组内存而存在数据危害？