启用Constant Throughput Timer后JMeter执行结果不完整问题排查

问题原因 #

1. Constant Throughput Timer（CTT）的工作机制：CTT不会中途终止线程，而是通过强制线程延迟来控制整体吞吐量。当线程数（350）远高于所需TPS（18）时，绝大多数线程会处于等待状态，只有极少数线程能被调度执行采样器。由于测试持续时间固定（3600秒），很多线程在测试结束前还没轮到执行后面的端点就停止了，导致汇总报告仅包含初始部分端点。
2. 线程迭代次数被摊薄：无限循环+固定持续时间的配置下，高线程数会大幅减少每个线程的迭代次数。18TPS意味着每秒仅18个采样被执行，350个线程争抢这18个执行名额，每个线程平均每19秒才能完成一次迭代，测试期间每个线程仅能完成约180次迭代。如果端点列表超过100个，部分线程可能还没遍历完所有端点，测试就已结束。
3. CTT参数影响调度逻辑：调整CTT的目标吞吐量或线程数时，线程的等待时间和执行优先级会变化，能抢到执行名额的线程数量、每个线程能完成的迭代步骤也会随之改变，因此已执行的端点数量会出现波动。

解决方案（同时满足350活跃用户+18TPS+全端点覆盖） #

1. 优化CTT作用范围 #

将CTT的“当前线程组所有活跃线程共享”选项改为每个线程单独控制吞吐量。计算单线程目标吞吐量：总TPS 18 ÷ 350个线程 ≈ 0.0514次/秒（或≈3.08次/分钟）。这样每个线程都会按固定频率执行迭代，不会出现大量线程长期等待的情况，所有线程都有机会遍历完所有端点。

2. 用吞吐量控制器保障全端点执行 #

给每个端点（或端点分组）添加Throughput Controller，选择“Total Executions”模式，根据测试总时长和TPS分配每个端点的执行次数。比如总测试时长3600秒，总采样数=18×3600=64800，100+端点平均每个执行约600次。这样即使CTT控制整体TPS，每个端点也会被执行指定次数，确保全端点覆盖。

3. 调整线程迭代逻辑 #

放弃无限循环，改为设置固定循环次数：每个线程的迭代间隔≈350÷18≈19.4秒，3600秒内每个线程可完成≈3600÷19.4≈185次迭代。将线程组的循环次数设为185，这样每个线程会在测试期间完成多次全端点遍历，既保证活跃用户数，又覆盖所有端点。

4. 协调思考时间与CTT #

保留Flow Action Controller的5-15秒随机思考时间，CTT的吞吐量控制会自动包含思考时间的影响，无需额外调整——它会自动调整线程的额外延迟，确保最终TPS符合预期。

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