least_conn压测核心是验证高并发下是否持续将请求导向最空闲节点：需在响应不均场景检验连接分配倾向性、慢节点绕过能力、连接分布均衡性及keepalive稳定性。
直接测 least_conn 在极限压测下的稳定性，关键不是“它能不能用”，而是验证它是否真正在高并发、长连接、响应不均的场景下，持续把请求导向最空闲的后端节点，并避免单点过载或雪崩。下面从测试目标、环境准备、执行要点和效果验证四方面说清楚。
明确测试要回答的核心问题
least_conn 不是万能算法，压测前先锁定你要验证的具体行为：
- 在后端响应时间差异明显（比如有的节点耗时 50ms，有的 800ms）时，新连接是否真的优先落到连接数少的节点上
- 当某台后端因慢响应堆积大量活跃连接，least_conn 是否能快速绕过它，防止请求排队恶化
- 集群整体吞吐达到平台期后，各后端的活跃连接数分布是否比轮询更均衡（极差缩小、标准差下降）
- 配合 keepalive 使用时，Nginx 连接复用是否稳定，有没有因连接池耗尽导致新建连接激增、least_conn 统计失真
搭建可信的压测链路
结果失真的常见原因是链路没还原真实场景。必须满足三个硬条件：
- 压测机与 Nginx 分离部署：不能用同一台机器既发压又跑 Nginx，否则 CPU/网络打满会影响分发逻辑判断
- 后端响应可控且统一：关闭后端缓存、固定响应体大小、禁用异步延迟逻辑；用 mock 服务或统一 sleep 控制不同节点的响应时间（例如 A 节点 sleep 100ms，B 节点 sleep 600ms）
- 清空干扰因素：停掉无关日志写入、关闭 proxy_cache、确保 stub_status 开启以便实时查连接数；健康检查参数（max_fails / fail_timeout）保留，但避免在压测中误判节点下线
用 wrk 做分阶段压测并观察指标
推荐用 wrk（而非 ab），因为它支持长连接、可设连接数和线程数，更贴近 least_conn 的生效条件：
- 第一阶段：从 1000 RPS 起步，每 30 秒加 500 RPS，直到 P95 延迟突增或错误率上升（如 > 1%）
- 第二阶段：在疑似瓶颈点稳压 2–3 分钟，重点采集：
– 每台后端的活跃连接数（通过 stub_status 的 Active connections 或自定义后端计数器）
– Nginx upstream 监控中的nginx_upstream_requests_total和nginx_upstream_response_time_seconds
– 各后端的 CPU、TCP ESTABLISHED 数、TIME_WAIT 数 - 对比 baseline：同样流量下，换用 round-robin 算法再压一次，看连接数分布标准差是否明显增大、慢节点错误率是否升高
验证 least_conn 是否真正起效
不能只看 access.log 或平均 QPS，要抓实时、可归因的数据：
- 启用
upstream日志变量：在 log_format 中加入$upstream_addr和$upstream_connect_time，分析连接建立是否倾向低连接数节点 - 用 stub_status + curl 实时轮询：
curl http://localhost/stub_status | grep 'Active connections'，配合后端暴露的 /actuator/metrics/http.server.requests（Spring Boot）或自定义指标，做秒级对齐 - 关注“连接数漂移”现象：如果某节点连接数持续高于均值 2 倍以上，检查它是否被健康检查标记为 down、是否有 keepalive 复用失败（看 Nginx error.log 中 “no live upstreams” 类报错）
- 故障注入验证：手动 kill 一台后端进程，观察 least_conn 是否在 30 秒内（fail_timeout）自动剔除，并将流量重分配到其余节点，同时连接数分布是否快速收敛
