跳到主要内容

并发公式

客户给出的指标（「5000 个用户」「支撑 200 TPS」）如何换算为压测配置。 术语定义见基本概念。

这些换算表面是算术问题，但算错的代价很高：得到的不是偏差略大的数字， 而是证据看起来确凿的错误结论——报告明确显示阈值失败、命令返回失败状态， 在客户现场即被解读为系统无法支撑。而实际上系统正常，是压测端配置有误。 本页末尾附一例实测记录。

一、并发用户数 ≠ 吞吐量​

两者通过思考时间（用户两次操作之间的停顿）关联：

吞吐量（迭代/秒） = 并发用户数 ÷ 单次迭代耗时（秒）

单次迭代耗时 = 请求耗时之和 + 思考时间

因此「50 个并发用户」对应多少 TPS，取决于单次操作的耗时。 同为 50 个 VU，系统快时吞吐高、系统慢时吞吐低。

以并发数近似吞吐量无法测出真实上限

load 模型控制的是并发用户数。系统响应变慢时每个 VU 的发起速率随之下降， 压力自动回落，因而始终无法触及系统真实上限， 测得的是受系统自身速度限制的伪平衡点。

客户验收指标为吞吐量时，必须使用 throughput 模型按到达率加压： 速率不随系统变慢而调整，处理不及时则累计 dropped_iterations。

二、到达率 ≠ HTTP RPS​

throughput 模型里设的到达率，单位是工作流迭代/秒，不是 HTTP 请求/秒。

实际 RPS ≈ 到达率 × 各工作流的平均步骤数（按权重加权）

单条链路可含 30 余个 HTTP 步骤（见场景列表）， 因此设定 50 迭代/秒可能对应上千 RPS。与客户对齐时须先确认 所称 200 TPS 指 200 个业务操作还是 200 个 HTTP 请求。

单接口吞吐验收的做法

混合流量中单个接口仅占全部请求的少数，「整体 500 请求/秒」对应到该接口 可能仅数十 TPS，无法读出按接口设定的验收指标。

收敛至单条链路（仅启用一条单请求链路），到达率即等于该接口的 TPS，无需换算。

三、preAllocatedVUs 的标定​

到达率模型下，k6 需要足够多的 VU 才能按时发出请求。VU 不够时它会丢弃迭代， 而 dropped_iterations == 0 正是这个模型的核心判据—— 因此 VU 配置过低即判失败，表面看是系统无法支撑目标吞吐量，实际是压测端资源不足。

需要的 VU ≈ 目标到达率 × 单次迭代耗时（秒）

取值方法：从 baseline 或 load 的报告中取 iteration_duration 的 avg 与 p95， 以 avg 计算基准值，再按 p95 预留长尾余量。

一例实测记录​

某 dev 环境实测：迭代耗时 avg 1.86 秒、p95 5.2 秒。

算法需要的 VU
50 迭代/秒 × 1.86 秒（平均）≈ 93
50 迭代/秒 × 5.2 秒（长尾）≈ 261

当时 preAllocatedVUs 仅配置为 50，结果为：

  • 丢弃 475 次迭代，dropped_iterations 阈值失败、退出码非零；
  • 但 HTTP 失败率 0.00%、p95 仅 266 ms——系统未受任何影响。

该配置连 30 迭代/秒（需约 56 个 VU）都不足以支撑。 修复方式为将 preAllocatedVUs 提升至 200、maxVUs 提升至 500， 重跑后 dropped_iterations = 0，峰值 VU 为 200，未触及上限。

不应通过放宽 dropped_iterations 阈值来规避

放宽该阈值会掩盖真实的容量问题。正确做法是配置足量 VU。

出现迭代丢弃时的归因​

现象结论
延迟与错误率同时劣化系统确实无法支撑
延迟与错误率均正常压测端 VU 不足，需调整 preAllocatedVUs

四、思考时间的影响​

thinkTimeSeconds 为两次迭代之间的等待，用于模拟真实操作间隔，直接计入迭代耗时：

  • load / baseline：默认 1 秒，贴近真实用户节奏；
  • throughput：默认 0——按到达率加压时思考时间无意义， 仅会降低单个 VU 的产能，进而需要更多 VU。
调整 thinkTime 会连带改变实际吞吐

在 load 模型下将思考时间由 1 秒改为 0，等同于提高每个 VU 的发起频率， 实际压力显著高于「并发数未变」的直觉判断。调整前须明确所要模拟的场景。

五、并发数的确定方法​

客户给出的通常是注册用户总数，该值不是并发数。

峰值并发 ≈ 峰值同时在线人数 × 活跃系数

活跃系数指在线用户中同一时刻实际发起请求的比例。 用户多数时间处于阅读、思考等非请求状态，实际发起请求的瞬时占比很低。

该系数无通用值，取决于业务形态。可靠的确定方式有三种：

  1. 由生产监控反推 —— 依据客户现网的峰值 RPS 与平均响应时间反算；
  2. 由业务量反推 —— 如「每日处理 2 万个工单，80% 集中于 4 小时内」可直接算出峰值速率；
  3. 先测拐点再商定 —— 以 stress 模型测出容量拐点，再与客户确认其业务量是否会达到该水平。
不应接受「按 5000 用户加压」这类口径

5000 注册用户与 5000 并发相差两到三个数量级。 直接按注册用户数加压，或因配置不足而无法执行，或得出客户永远不会触及的结论。 应先明确口径，再设定目标并发。

六、相关页面​

内容页面
各压测模式的默认强度与适用场景压测模式
指标口径与验收判定性能测试指标
写入后的检索延迟（另一处易混淆的时间口径）索引时长