性能拐点是响应时间陡增、吞吐量塌陷、资源利用率饱和三线失衡的转折时刻，需在加压过程中实时联动分析RT、TPS和资源指标，结合调用链分层定位瓶颈，并区分真实拐点与限流、配置等假异常。
负载测试中识别系统性能拐点，核心是把“加压过程”和“指标变化”对应起来看——不是等压完再翻图，而是在每一轮并发递增时，同步盯住三类关键指标的联动关系：响应时间（RT）、吞吐量（TPS）、资源利用率（CPU/内存/磁盘IO/连接数）。拐点不是某个单一数值突破阈值，而是这三条曲线开始“失衡”的转折时刻。
盯住三线联动，而不是单点超限
真正有效的拐点判断，依赖三条曲线的相对走势：
- 响应时间（RT）：在轻压力区缓慢爬升（比如从200ms→300ms），进入重压力区后斜率变陡（300ms→800ms），到拐点区会突然跳升（800ms→3s+），且P95/P99明显拉长；
- 吞吐量（TPS）：随并发增长持续上升，到某一点后增速放缓，之后持平，再往后出现下降（比如从1200 TPS → 1220 → 1210 → 1150），这就是吞吐塌陷的明确信号；
- 资源利用率：CPU、内存、数据库连接数、线程池活跃数等，其中任一关键资源持续≥85%并伴随RT上扬、TPS停滞，就说明它正在成为瓶颈载体。
分层定位，从外到内排查拐点成因
发现三线失衡后，不能只说“系统扛不住了”，要按调用链向下穿透：
- 先看接入层：LB或网关的错误率是否突增？连接数是否打满？健康检查失败是否集中某几台实例？
- 再查应用层：JVM GC频率是否飙升？线程阻塞数是否上涨？慢接口是否集中在某个服务或某个SQL？
- 最后验依赖层：数据库连接池是否耗尽？慢查询数量是否激增？Redis命中率是否骤降？下游HTTP调用超时率是否超过10%？
结合业务语义，区分真拐点和假瓶颈
有些“指标异常”其实是设计使然，不是性能缺陷：
- 如果RT升高但TPS未降，且CPU/内存平稳，可能是业务逻辑主动限流（如秒杀场景的排队机制），属于可控策略，不是拐点；
- 如果TPS下降但错误率仍为0，且日志里大量出现“rejected execution”或“thread pool exhausted”，说明线程池配置过小，属可调优配置问题；
- 如果仅某类复杂事务（如导出报表）RT飙升，而登录、查询等主干链路正常，说明瓶颈在特定功能模块，不是系统级拐点。
用“最佳并发点”反推拐点位置
拐点前有一个更实用的参考点：最佳并发用户数。它出现在RT仍较平缓、TPS接近峰值、资源利用率约70%~80%的位置。这个点代表系统效率最高——用户等待少、资源没浪费。拐点通常落在最佳并发点之后1.2~1.5倍并发处。压测时标记出这个区间，比死守“TPS下降10%”更贴近实际运维决策。
