如何在 Gatling 中注入恒定数量的用户？
How to inject a constant number of users in Gatling?
我不清楚如何在 Gatling 中控制封闭的工作负载模型。
如果我使用 constantConcurrentUsers，像这样：
myScenario.inject(
constantConcurrentUsers(40) during (2 minutes)
)
我以为这意味着活跃用户数会保持不变。但相反，我收到这样的报告：
用户数量不稳定，比我想要的多 3-5 倍。
虽然在控制台输出中，我可以看到 某物 是恒定的（这里有 4 个场景，每个场景加载 10 个恒定的并发用户）：
但总负载比我预期的要多得多。
节流我试过，结果很明显。以我的理解，节流阀最大化并发活动请求的数量（如果请求已发送但尚未响应，则该请求是活动的）。我定义了一些应该通过的请求，Gatling 每次完成后都会发送一个新请求。并且由于响应时间之间没有太大差异，因此报告如下所示：
我想做同样的事情，但这样我就可以控制模拟的长度，而不是发送的请求总数。 constantConcurrentUsers 似乎正是我需要的东西，但它产生了意想不到的结果。我的油门模拟在油门为50的情况下在1分钟左右做了大约3000个请求。同时，如果我设置50个并发用户1分钟，报告中发送了7000多个请求。节气门情况下的响应时间要短得多。因此节流模拟发送请求比并发用户模拟慢得多，但不是因为请求花费更多时间。
我知道活跃用户和发送的请求是不一样的，constantConcurrentUsers 控制用户数量，而节流控制请求。但是我所有的场景都只包含一个请求，所以我不明白结果之间的区别。
所以我的问题是：
- 当我使用
constantConcurrentUsers 时，到底什么是常数？
- 我使用
constantConcurrentUsers时请求数是怎么计算的？
- 报表中的"active users"和控制台输出中的"active"有什么关系？
我已阅读 this part of the Gatling documentation, which is really short and lacks a detailed description. I also read this article，其中包含我在任何 Gatling 报告中从未见过的图表，并且没有回答我的问题。
感谢您的贡献。
我发现 Cheatsheet 最准确地描述了每个注射步骤。如何注入固定数量的用户应该使用 constantConcurrentUsers，在备忘单中描述为："Maintain a constant number of concurrent users"
关于您的其他问题：
- What exactly is constant when I use constantConcurrentUsers?
我相信加特林确实能保持并发用户数不变。请求数量出现峰值的原因是一个用户可以在给定的时间跨度内发出多个请求。一旦用户的当前请求完成，同一用户就会触发一个新请求。在您的示例中，您有 40 个 users 而您的 number of requests 看起来大约为 80，这表明每个用户每秒实现 2 个请求（平均响应时间约为 500 毫秒？）
- How is the number of requests calculated when I use constantConcurrentUsers?
如上所述，您的并发用户将在您设置的持续时间内不断循环请求，并且在当前请求提供响应之前不会触发另一个请求。如果您的 API 很快，您每秒的请求数将高于您的用户数。
- What is the relation between "active users" in the report and "active" in the console output?
这实际上是我有点不确定的地方：/我在测试中设置了 10 constantConcurrentUsers，并且控制台显示与您的类似，但我的报告显示随着时间的推移有 10-75 个活跃用户
但是，Gatling 文档中的这个 Reports 页面提供了一些启示：
“Active users” is neither “concurrent users” or “users arrival rate”.
It’s a kind of mixed metric that serves for both open and closed
workload models and that represents “users who were active on the
system under load at a given second”.
It’s computed as:
(number of alive users at previous second)
+ (number of users that were started during this second)
- (number of users that were terminated during previous second)
我不清楚如何在 Gatling 中控制封闭的工作负载模型。
如果我使用 constantConcurrentUsers，像这样：
myScenario.inject(
constantConcurrentUsers(40) during (2 minutes)
)
我以为这意味着活跃用户数会保持不变。但相反，我收到这样的报告：
用户数量不稳定，比我想要的多 3-5 倍。
虽然在控制台输出中，我可以看到 某物 是恒定的（这里有 4 个场景，每个场景加载 10 个恒定的并发用户）：
但总负载比我预期的要多得多。
节流我试过，结果很明显。以我的理解，节流阀最大化并发活动请求的数量（如果请求已发送但尚未响应，则该请求是活动的）。我定义了一些应该通过的请求，Gatling 每次完成后都会发送一个新请求。并且由于响应时间之间没有太大差异，因此报告如下所示：
我想做同样的事情，但这样我就可以控制模拟的长度，而不是发送的请求总数。 constantConcurrentUsers 似乎正是我需要的东西，但它产生了意想不到的结果。我的油门模拟在油门为50的情况下在1分钟左右做了大约3000个请求。同时，如果我设置50个并发用户1分钟，报告中发送了7000多个请求。节气门情况下的响应时间要短得多。因此节流模拟发送请求比并发用户模拟慢得多，但不是因为请求花费更多时间。
我知道活跃用户和发送的请求是不一样的，constantConcurrentUsers 控制用户数量，而节流控制请求。但是我所有的场景都只包含一个请求，所以我不明白结果之间的区别。
所以我的问题是：
- 当我使用
constantConcurrentUsers时，到底什么是常数？ - 我使用
constantConcurrentUsers时请求数是怎么计算的？ - 报表中的"active users"和控制台输出中的"active"有什么关系？
我已阅读 this part of the Gatling documentation, which is really short and lacks a detailed description. I also read this article，其中包含我在任何 Gatling 报告中从未见过的图表，并且没有回答我的问题。
感谢您的贡献。
我发现 Cheatsheet 最准确地描述了每个注射步骤。如何注入固定数量的用户应该使用 constantConcurrentUsers，在备忘单中描述为："Maintain a constant number of concurrent users"
关于您的其他问题：
- What exactly is constant when I use constantConcurrentUsers?
我相信加特林确实能保持并发用户数不变。请求数量出现峰值的原因是一个用户可以在给定的时间跨度内发出多个请求。一旦用户的当前请求完成，同一用户就会触发一个新请求。在您的示例中，您有 40 个 users 而您的 number of requests 看起来大约为 80，这表明每个用户每秒实现 2 个请求（平均响应时间约为 500 毫秒？）
- How is the number of requests calculated when I use constantConcurrentUsers?
如上所述，您的并发用户将在您设置的持续时间内不断循环请求，并且在当前请求提供响应之前不会触发另一个请求。如果您的 API 很快，您每秒的请求数将高于您的用户数。
- What is the relation between "active users" in the report and "active" in the console output?
这实际上是我有点不确定的地方：/我在测试中设置了 10 constantConcurrentUsers，并且控制台显示与您的类似，但我的报告显示随着时间的推移有 10-75 个活跃用户
但是，Gatling 文档中的这个 Reports 页面提供了一些启示：
“Active users” is neither “concurrent users” or “users arrival rate”. It’s a kind of mixed metric that serves for both open and closed workload models and that represents “users who were active on the system under load at a given second”.
It’s computed as:
(number of alive users at previous second) + (number of users that were started during this second) - (number of users that were terminated during previous second)