least_conn的并发极限测试核心是验证其在真实压力下是否持续将新连接导向最空闲节点。需构造响应差异后端、用wrk长连接压测、实时监控各节点活跃连接数，并与round_robin对比P95延迟、错误率及连接分布标准差。
测试 least_conn 的并发处理极限，核心不是看它“能不能扛住高并发”，而是验证在真实压力下，它是否持续把新连接导向当前最空闲的后端节点——尤其当节点响应不均、连接堆积、长连接持续占用时，能否避免单点过载。
构造响应差异明显的后端环境
least_conn 的价值在节点负载不一致时才凸显。必须人为制造响应时间差，否则所有节点连接数接近，算法无法体现优势：
- 用 mock 服务或 sleep 控制不同后端响应：例如 A 节点固定返回 100ms，B 节点固定 700ms，C 节点 50ms
- 关闭后端缓存与异步延迟逻辑，确保响应时间稳定可复现
- 所有后端启用 HTTP/1.1 + keepalive，并禁用主动断连（如 linger=0），保证连接数统计真实反映调度状态
用 wrk 模拟长连接并发压测
短连接工具（如 ab）会掩盖 least_conn 的调度行为，必须用支持长连接、可控并发模型的工具：
- 启动 wrk，指定高并发连接数和长连接保持：`wrk -t4 -c2000 -d120s --timeout 10s http://nginx-lb/api/longpoll`
- 压测目标应为长轮询接口（sleep 5–10 秒），让连接真实堆积，触发 least_conn 的“避让”逻辑
- 过程中持续发新请求（模拟用户不断接入），观察新连接是否绕开已堆积大量 ESTABLISHED 连接的慢节点
实时验证连接分配是否符合 least_conn 逻辑
不能只看平均 QPS 或日志请求数，要抓取可归因的实时指标：
- 开启 stub_status，每 5 秒调用 `/nginx_status`，记录各 upstream server 的
Active connections值变化趋势 - 对比压测中同一时刻各后端的
ss -tn src :8080 | grep ESTAB | wc -l实际连接数，确认分布极差是否明显小于 round-robin 场景 - 若某节点连接数长期显著偏高，检查是否未配置健康检查（
max_fails/fail_timeout）、或keepalive值过大导致空闲连接占满“账面名额”
交叉比对 baseline 与瓶颈拐点
单独跑一次 least_conn 不够，需对照验证才能确认其有效性：
- 相同压测参数下，切换 upstream 为
round_robin，重复压测，对比两组的 P95 延迟突增点、错误率上升阈值、以及各后端连接数标准差 - 当整体吞吐达平台期时，least_conn 下慢节点的错误率应明显更低，且集群总连接数更趋近于均匀分布
- 记录 Nginx worker 进程 CPU、内存及
worker_connections使用率，确认瓶颈是否来自上游而非 Nginx 自身
