关于VU指标统计异常的咨询：请求数与迭代分配问题

你这明显踩了负载测试工具里一个超常见的坑——混淆了「全局总迭代数」和「每个VU的迭代数」，结合你描述的现象和工具提示，问题根源非常清晰：你设置的iterations参数是所有VU共享的总迭代次数，而非每个VU要执行的迭代次数。

先拆解你的两次测试现象： #

• 第一次测试（100VU、2次迭代）：工具实际只执行了2次全局迭代，大概率是其中1个VU抢到了这2次执行权，完成了77个请求（也就是你说的单VU应完成的请求量），剩下99个VU根本没机会跑任何迭代，所以最终http_reqs只有77。
• 第二次测试（1000VU、100次迭代）：全局总共仅跑100次迭代，分给1000个VU，自然大部分VU轮不到执行；而每个迭代对应一条数据库记录，所以最终只新增100条，http_reqs3803就是这100次迭代的总请求量，远低于你预期的1000*100次迭代的请求数。

工具提示的「所有迭代由所有VU共享」其实已经把问题点透了，只是一开始没get到它的含义——这个参数不是给每个VU分配迭代数，而是所有VU一起抢这部分迭代额度。

解决方法： #

要实现每个VU执行指定次数的迭代，你需要调整工具配置（以常用的k6为例，其他工具逻辑类似）：

1. 使用Per-VU迭代配置：
   如果工具支持（比如k6的perVUIterations选项），直接配置每个VU的迭代次数：

   export const options = {
     vus: 100, // 100个并发用户
     perVUIterations: 2, // 每个VU执行2次迭代
   };
   

2. 脚本内循环控制：
   如果工具不支持Per-VU迭代参数，就在测试脚本里手动加循环，让每个VU重复执行指定次数：

   export default function () {
     // 每个VU执行100次迭代
     for (let i = 0; i < 100; i++) {
       // 这里放你的测试逻辑：发送HTTP请求、插入数据库等
       // 注意：如果有异步操作要确保等待完成，避免迭代提前结束
     }
   }
   

额外排查点： #

• 检查测试脚本是否有未处理的错误：比如请求失败、数据库连接超时导致VU提前退出，也会减少实际执行的迭代数；
• 核对每个迭代的请求数：确认你的迭代逻辑里确实包含了所有预期的请求，没有条件分支导致部分请求被跳过；
• 查看工具的详细日志：很多负载测试工具会输出VU的执行情况，能看到哪些VU没执行迭代、有没有报错。

内容的提问来源于stack exchange，提问作者lapots