例如，对于 constant-arrival-rate 执行器和 rate: 10，k6 尝试每 100 毫秒开始一次新的迭代。如果场景配置为 rate: 10, timeUnit: '1m'，k6 尝试每 6 秒开始一次新的迭代。它是否能够开始目标迭代速率取决于分配的 VU 数量是否足够。

export const options = {
  scenarios: {
    constant_load: {
      executor: 'constant-arrival-rate',
      preAllocatedVUs: 10,
      rate: 10,
      timeUnit: '1m',
    },
  },
};

在实践中，确定能够达到目标迭代速率所需的正确 VU 数量可能需要一些尝试和错误，因为所需的 VU 完全取决于您的迭代代码是什么样的以及被测系统处理请求的速度。

k6 如何使用分配的 VU

在到达率场景开始之前，k6 首先初始化 preAllocatedVUs 的数量。当测试运行时，可用的 preAllocatedVUs 数量决定了 k6 可以开始多少次迭代。k6 尝试达到目标每秒迭代次数，此时会发生以下两种情况之一

如果执行器	则..
拥有足够的 VU	多余的 VU 处于“空闲”状态，可在需要时使用。
VU 不足。	k6 会为无法运行的每次迭代发出一个 `dropped_iterations` 指标。

迭代持续时间影响必要的分配

必要的分配取决于迭代持续时间：持续时间越长，所需的 VU 越多。

在一个理想的世界里，您可以用这个公式估算预分配的 VU 数量

preAllocatedVUs = [median_iteration_duration * rate] + constant_for_variance

在现实世界中，如果您精确地知道一次迭代需要多长时间，您可能就不需要运行测试了。更重要的是，随着测试的进行，迭代持续时间可能会增加。如果响应时间变慢，导致 k6 缺少 VU 来按所需速率开始迭代，则分配可能不足，k6 将会丢弃迭代。

要确定您的策略，您可以在本地运行测试并逐步增加预分配的 VU 数量。由于丢弃的迭代也可能表明系统性能正在下降，这种早期实验本身就可以提供有用的数据。

您可能不需要 `maxVUs`

注意
在云测试中，maxVUs 的数量会计入您的订阅额度，会覆盖 preAllocatedVUs 设置的数量。

到达率执行器也有一个 maxVUs 属性。如果您设置了它，k6 将按此顺序运行

预分配 preAllocatedVUs。
运行测试，尝试达到目标迭代速率。
如果目标超出可用 VU，则分配另一个 VU。
如果目标仍然超出可用 VU，则继续分配 VU，直到达到由 maxVUs 设置的数量。

尽管看起来很方便，但在大多数情况下应避免使用 maxVUs。分配 VU 会产生 CPU 和内存成本，并且在测试运行时分配 VU 可能会使负载生成器过载并扭曲结果。在云测试中，maxVUs 的数量会计入您的订阅额度。这是因为 k6 必须为 maxVUs 分配足够的资源以进行初始化，即使它们从未被使用。在几乎所有情况下，最好的做法是提前预分配所需的 VU 数量。

在某些情况下使用 maxVUs 可能有意义，这些情况包括