容量基准测试的核心目标是确认预期负载下最先扛不住的环节，关键通过tps与响应时间拐点、错误率与资源峰值对应、分段耗时归属、接口差异对比等多维指标联动，定位首要短板并归因排除。

容量基准测试的核心目标，不是看系统“能不能跑”，而是确认“在预期负载下，哪一环最先扛不住”。压测报告本身不直接写“瓶颈是数据库”，但会通过几组指标的联动异常，给出清晰线索。关键在于横向比对、纵向追踪、交叉验证。

看响应时间与吞吐量的拐点是否同步

真正有意义的“短板信号”，往往出现在TPS不再随并发线性增长、而响应时间却开始明显爬升的那个临界点。比如：并发从400升到500时，TPS只涨了5%，但平均响应时间跳升40%，P95从200ms飙到850ms——这说明系统已进入非线性退化区。此时必须回溯该拐点时刻的全链路数据，而不是只盯最终汇总值。

查错误率突增与资源利用率峰值的对应关系

错误率（尤其是5xx或超时）突然上升，通常不是孤立事件。要立刻对照同一时间窗口的资源监控：

• CPU持续＞90%且应用线程池活跃数打满 → 可能是计算密集型瓶颈，如未优化的算法或同步锁竞争
• 数据库连接池使用率100%、等待连接线程数激增、DB响应时间同步飙升 → 几乎可锁定为数据库连接或慢查询瓶颈
• 内存使用率缓升但Full GC频率陡增、每次GC耗时超200ms → JVM堆配置或对象生命周期设计有问题

拆解响应时间构成，定位延迟归属层

单看“后端RT=1200ms”没意义。需有分段耗时数据（如客户端发包→服务端接收→业务逻辑→DB执行→返回网络），常见分布模式有：

• DB耗时占RT 70%以上，且DB自身监控显示I/O等待高 → 数据库层瓶颈
• 服务端处理耗时长，但CPU不高、GC正常 → 可能是外部依赖（如第三方HTTP调用阻塞、消息队列积压）
• 网络传输耗时波动大、与客户端地理位置强相关 → 网络或CDN问题，非后端短板

对比不同接口的资源消耗强度

同一压测场景下，几个核心接口的TPS、错误率、RT走势差异很大，说明瓶颈具有接口特异性。例如：

• 订单创建接口TPS骤降、错误率跳升，但用户查询接口依然平稳 → 问题大概率出在写操作路径（如事务锁、库存扣减逻辑、ES同步）
• 所有写接口都异常，读接口正常 → 可能是主库负载过高、binlog堆积、或分布式事务协调器过载

识别首要短板，本质是做“归因排除”：哪个指标最先越界？它和哪些其他指标同步恶化？这个恶化是否集中在特定组件或操作类型？把这三个问题答清楚，报告里的数字就自然指向了根因。