固定几个线程等响应再发下一次请求，服务变慢时客户端发得也更慢，可能掩盖真实排队压力。
本文使用有限容量的 Java 服务与固定输入的实验负载。性能问题需要同时看吞吐、排队、错误和延迟分布。示例数字用于演算与设计实验，不代表任何真实系统已经达到的性能成绩。
1. 从现象推到机制
闭环负载的下一次请求依赖上次完成，开放式到达模型则按计划产生流量。两种模型回答不同问题。只统计已完成请求，会忽略超时、拒绝与未完成等待，平均延迟也可能显得过于乐观。
图中的四个节点分别表示负载模型、发送证据、完成结果、结论范围。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先说明目标是模拟固定用户还是固定到达率。压测机同步记录计划发送、实际发送、完成与超时数量，确认客户端没有先耗尽资源。
1
2
3
planned arrivals -> actual sends
actual sends -> completed + timed_out + in_flight
report: rate, errors, percentiles, unfinished work
从稳定低负载开始增加压力，分别记录进入与完成速率。固定请求数据、连接策略和观察窗口，保留错误响应；只有成功请求的平均耗时不足以代表系统体验。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 服务变慢而客户端也降速 | 闭环模型可能降低施加压力 |
| 只计算成功请求延迟 | 会遗漏最差的失败体验 |
| 压测机 CPU 达到上限 | 瓶颈可能先出现在客户端 |
对照 1：服务变慢而客户端也降速
闭环模型可能降低施加压力。观察时记录实际发送率与计划发送率。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：只计算成功请求延迟
会遗漏最差的失败体验。观察时记录错误和未完成请求数量。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：压测机 CPU 达到上限
瓶颈可能先出现在客户端。观察时记录两端资源与网络使用。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
压测结论必须带上数据、硬件、请求组合和运行时间。不能把一条轻量接口的峰值外推成全系统可承受的订单并发。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“压测机 CPU 达到上限”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
