least_conn在长连接和混入慢接口场景下显著优于轮询：连接分布更均衡、p95延迟低30%以上、吞吐量高15%–25%、错误率下降；需配合健康检查与max_conns防假死和过载。
直接压测就能看出 least_conn 在不同业务场景下的实际效果，关键不是“能不能用”，而是“在什么情况下它比轮询多扛多少请求”。测试要围绕连接行为和响应时间波动来设计，而不是只看 QPS 数字。
选对压测工具和指标
用 wrk 或 hey 这类支持长连接、可设并发数和持续时间的工具，避免 ab 这种短连接为主的旧工具干扰连接数统计。重点盯三个指标：
- 各后端节点的活跃连接数（通过 Nginx stub_status 或 /nginx_status 接口实时抓取）
- 平均响应时间与 P95/P99 延迟（尤其关注是否出现长尾突刺）
- 超时请求数和 502/504 错误率（反映节点是否被拖垮）
模拟长连接场景（如 WebSocket、gRPC）
启动 1000 个长期保持的连接，每个连接每 5 秒发一次小请求。观察 10 分钟内：
- 轮询模式下，某台后端连接数快速升到 800+，其余两台只有 200 左右；
- least_conn 模式下，三台连接数始终在 300–400 区间浮动，偏差不超过 15%；
- 此时 least_conn 的 P95 延迟通常比轮询低 30% 以上，超时几乎为 0。
混入慢接口（如报表导出、AI 推理）
让 20% 的请求走耗时 5–10 秒的慢接口，其余走毫秒级查询。对比两种策略：
- 轮询容易把连续多个慢请求打到同一台机器，导致其连接堆积、后续快请求也被卡住；
- least_conn 会自动绕开已接了 3 个慢请求的节点，把第 4 个慢请求分给连接数为 0 的空闲节点；
- 实测中，这种场景下 least_conn 的整体吞吐量常高出 15%–25%，且错误率下降明显。
验证健康检查与 max_conns 协同效果
手动让一台后端服务变慢（比如加 sleep(8)），或直接 kill 其进程但不关闭端口（模拟假死）。这时：
- 若没配健康检查，least_conn 仍可能把新请求发给那个“连接数低但已卡死”的节点；
- 配上 max_fails=2 fail_timeout=10s 后，该节点会在两次失败后被标记为不可用，连接数统计失效，请求自动跳过；
- 再叠加 max_conns=500，能防止高性能节点被突发流量打满，让负载更平稳。
