least_conn能显著提升长任务并发吞吐，其通过优先调度连接数最少的后端减少排队；需部署多台sleep 5–10秒的长轮询后端，Nginx配置least_conn+keepalive，并用wrk压测验证连接分布均衡性。
直接用长轮询接口压测，就能看清 least_conn 在长任务并发下是否真能提升吞吐。它不比响应快慢，只看哪个后端当前“手头活最少”——连接数低，就优先派新请求过去，从而减少排队、避免雪崩。
准备可模拟长任务的后端服务
部署至少两台后端，每台提供一个稳定可控的长轮询接口：
- 返回前 sleep 5–10 秒（模拟等待事件或慢查询），确保响应时间明显拉长
- 使用 HTTP/1.1 并开启 keepalive，禁用后端主动断连（如设 tcp_linger=0），防止 Nginx 误判连接已释放
- 关闭后端缓存与异步延迟逻辑，让每条请求真实占用连接资源
配置 Nginx upstream 启用 least_conn 和连接池
在 upstream 块中明确启用 least_conn，并配好 keepalive：
- least_conn; 是核心，必须单独成行
- keepalive 32;（推荐值 16–100），复用连接，避免短连接干扰连接数统计
- 在 location 中补全代理头：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 搭配健康检查：max_fails=2 fail_timeout=30s，防止故障节点持续被选中
用 wrk 持续发起长连接压测
不用 ab 或 curl 脚本，改用支持长连接的 wrk：
- 并发 100+ 连接，每个连接持续发起长轮询请求（直到后端返回）
- 运行 60 秒以上，期间保持新连接不断接入（模拟真实用户增长）
- 观察各后端 access log 的请求数分布：least_conn 下应明显更均衡，尤其当某台因 sleep 堆积连接时，新请求会自动绕开
通过 stub_status 实时验证调度效果
开启 stub_status 模块，访问 /nginx_status 查看每台后端的活跃连接数：
- 压测中对比 conn_active 数值变化，确认 Nginx 确实在选“数字最小”的那个节点
- 若某台连接数持续远高于其他节点，检查是否健康检查未生效，或 keepalive 值过大导致空闲连接占满“账面名额”
- 配合同样流量下 round-robin 对照测试，看连接数极差和标准差是否显著缩小
