并发乘的是时延
客户端并发数与吞吐的关系可以用一个粗略但可靠的式子表达：吞吐 ≈ 并发数 ÷ 平均单次请求时延。后端尚未饱和时，提高并发几乎线性换取吞吐；一旦链路中某一段（客户端网卡、存储前端端口、后端盘组、元数据服务）进入饱和，多出来的并发只会排队，表现为时延持续上涨而吞吐纹丝不动。判断该不该加并发，先看时延随并发上升的斜率，而不是只看吞吐数字。
基本信息
| 核心变量 | 并发线程/进程数、单请求大小、队列深度 |
|---|---|
| 观测位置 | 客户端线程与 CPU、网络收发、后端盘与队列 |
| 常用手段 | 多进程压测、分片并发上传下载、连接池大小 |
| 饱和信号 | 时延上升而吞吐不变，后端队列持续非空 |
| 常见误区 | 并发越高越好、只测平均值不看分布 |
典型使用场景
- 迁移与备份：需要用多线程把带宽打满，但要避免压垮目标端
- 大文件传输：单个流受限于单连接带宽，需要分片并发
- 海量小文件：请求数受限，靠提高并发争抢吞吐上限
- 压测定位：逐步加并发，找到吞吐拐点与对应瓶颈
- 多客户端共享集群：需评估总量而非单客户端最优值
找拐点的方法
找拐点的方法
# 1) 固定并发为 1，测出单请求平均时延与单流吞吐
# 2) 按 2、4、8、16 逐档加并发，每档稳定运行数分钟再记录
# 3) 记录三条曲线：吞吐、平均时延、时延 99 分位
# 4) 找到吞吐不再增长的那一档，就是本链路的饱和点
# 5) 在饱和点回看各段指标：谁先到 100%，谁就是瓶颈
# 6) 生产并发取饱和点的 60%~70%，给突发流量留余量现象对照与判读
| 现象 | 含义 | 处理方向 |
|---|---|---|
| 吞吐随时延一起涨 | 尚未饱和，可以继续加并发 | 继续加压直到出现拐点 |
| 时延翻倍吞吐不变 | 某一段已饱和，并发只在排队 | 回退并发，定位饱和段 |
| 平均时延尚可但毛刺剧烈 | 队列偶尔积压，分布被拉长 | 关注高分位时延，降低瞬时并发 |
| 加并发后吞吐反而下降 | 元数据或锁竞争被放大 | 减少请求数，合并小操作 |
| 单客户端到顶但集群未满 | 瓶颈在客户端自身资源 | 增加客户端数量或提升单机资源 |
平均值会掩盖问题：同一个平均时延，可能是「全部请求都快」也可能是「大多数很快、少数极慢」。评估用户感受与超时率必须看 95 与 99 分位。
前端后端都还没饱和时，把并发拉到极高的风险在于后端队列被填满，一旦某个节点抖动，重试会在队列里叠加放大，时延出现雪崩式抬升，恢复比提升慢得多。