最大承载边界是满足p95响应时间≤500ms、错误率
要通过压测精准探测负载均衡接入后系统的最大承载边界，关键不是“压到崩”，而是用可归因、可复现、可对比的方式，把系统从“能跑”推到“临界稳态”，再识别出那个不可持续的拐点。
明确“最大承载边界”的真实含义
它不是某次压测跑出的最高并发数，而是满足以下三者同时成立的负载水平：
- P95响应时间未突破业务容忍阈值（如核心接口 ≤ 500ms）
- 错误率稳定在可接受范围（如 HTTP 5xx
- 各后端资源利用相对均衡（CPU极差 ≤ 35%，活跃连接数标准差 ≤ 均值的40%）
分阶段阶梯加压，锁定平台期拐点
用 wrk 或 JMeter 的 Concurrency Thread Group 实施可控增长：
- 起始并发设为 200，每 45 秒增加 100 并发，每阶稳压 120 秒
- 每阶同步采集：Nginx upstream 的 active connections、各后端的 ESTABLISHED 连接数、P95 延迟、5xx 比率
- 当 TPS 增速明显放缓（如上一阶 +100 并发带来 +85 TPS，本阶仅 +22 TPS），且 P95 上升超 30%，即进入吞吐平台期——此时的 TPS 就是当前配置下的最大可持续吞吐量
注入差异化后端特征，验证负载均衡算法是否真起作用
单纯看总吞吐会掩盖调度失衡。必须构造差异场景：
- 让一台后端固定 sleep 800ms，其余 sleep 120ms，观察 least_conn 是否快速绕过慢节点（其活跃连接数应始终低于均值 60% 以上）
- 切换为 round-robin 对照压测，若慢节点错误率高出 5 倍、连接数极差扩大 2.3 倍，说明 least_conn 确实提升了边界上限
结合健康检查与连接池行为，抓真实瓶颈
很多“打满”其实是伪瓶颈：
- 关闭 Nginx 的 keepalive 或调小 upstream keepalive_requests，观察 TIME_WAIT 是否激增、新建连接是否陡升——这说明连接复用失效，实际瓶颈在 TCP 层而非业务层
- 若某节点在连接数未超限前提下 CPU 已达 90%，而其他节点仅 40%，需检查是否因 sticky session 或 IP hash 导致流量倾斜，而非系统承载力不足
不复杂但容易忽略。
