least_conn吞吐测试需构造可控长连接场景：部署多台响应延迟一致的后端，Nginx upstream启用least_conn与max_conns，用wrk阶梯压测并实时监控各节点活跃连接数及QPS变化。
要测试 Nginx 的 least_conn 负载均衡策略整体吞吐量，核心是构造可复现的并发请求场景，观察后端节点连接数分布与系统吞吐变化，并排除其他瓶颈干扰。
准备真实、可观测的后端服务
不能用 echo 或静态文件服务测试 least_conn，因为它依赖“活跃连接数”做调度决策。需部署多个能维持长连接或可控响应时间的后端（如轻量 HTTP 服务）：
- 每个后端暴露一个简单接口（如
/health），返回固定内容 + 响应头X-Backend-ID方便识别来源 - 后端启用连接日志，记录每次请求的开始/结束时间，或用
netstat -an | grep :port | wc -l实时采样 ESTABLISHED 连接数 - 确保所有后端性能一致（CPU、内存、网络延迟相近），避免因单点慢导致连接堆积，扭曲
least_conn效果
配置 Nginx 并开启关键监控项
在 upstream 块中明确启用 least_conn，并添加健康检查和连接限制：
upstream backend {
least_conn;
server 192.168.1.10:8080 max_conns=1024;
server 192.168.1.11:8080 max_conns=1024;
keepalive 32;
}
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
}
同时开启 Nginx 状态页（stub_status）或使用 nginx-module-vts，实时查看各 upstream server 的 Active connections 和请求计数。
用分阶段压测工具验证吞吐与连接分布
推荐使用 wrk 或 hey，禁用连接复用（避免掩盖 least_conn 的动态调度行为）：
- 第一阶段：低并发（如 50 线程），持续 60 秒，确认各后端连接数基本均衡（差值 ≤ 2）
- 第二阶段：阶梯加压（100 → 500 → 1000 → 2000 并发），每级跑 3 分钟，记录：
– 总 QPS（wrk 输出的 Requests/sec）
– 各后端 Active connections（每 10 秒抓一次）
– 错误率与 P95 延迟 - 重点观察：当某后端 Active connections 接近
max_conns时，QPS 是否骤降？新请求是否自动转向连接数更少的节点？
排除干扰因素，聚焦策略有效性
least_conn 的吞吐表现易被以下因素掩盖：
-
客户端连接复用：用
wrk -H "Connection: close"或hey -disable-keepalive强制新建连接，让调度器频繁决策 -
后端处理不均：若某个后端响应时间明显偏高，它会更快积累连接，但未必是吞吐瓶颈；需结合
time日志判断是调度问题还是服务性能问题 -
Nginx 自身瓶颈：检查
worker_connections是否足够，ulimit -n是否限制了最大文件描述符数
真正反映 least_conn 吞吐能力的指标，是“在连接数趋于均衡的前提下，系统稳定达到的最高可持续 QPS”。它通常略低于 round_robin（因连接建立开销略高），但在后端响应时间差异大时优势明显。
