长轮询压测可验证least_conn真实分发效果，重点观察连接堆积规避能力：部署多台后端模拟5–10秒延迟，nginx upstream启用least_conn与keepalive，用wrk等长连接工具并发压测，通过stub_status确认连接数实时均衡。
直接用长轮询（Long Polling）接口压测，就能观察 least_conn 在真实业务下的分发效果。它不看响应快慢，只盯每个后端当前有多少未关闭的连接，所以测试重点是“连接堆积是否被有效规避”。
准备一个典型的长轮询后端服务
部署至少两台后端，每台提供一个模拟长轮询的 HTTP 接口，例如：
- 返回前 sleep 5–10 秒（模拟等待事件）
- 使用 HTTP/1.1 + keepalive，避免短连接干扰连接数统计
- 确保后端不主动快速断连（如禁用 linger 或设为 0），否则 Nginx 会误判连接已释放
配置 upstream 启用 least_conn 和连接池
在 Nginx 的 upstream 块中明确启用 least_conn，并配 keepalive 提升稳定性：
upstream backend {
least_conn;
keepalive 32;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
同时在 location 中透传 Connection 头，复用连接：
- proxy_http_version 1.1;
- proxy_set_header Connection '';
用并发长连接持续压测
不用 ab 这类短连接工具，改用支持长连接的压测方式：
- 用 wrk 或自写脚本，发起 100+ 并发，每个请求保持连接直到服务返回（即真正长轮询）
- 运行 30–60 秒，期间持续新请求接入（模拟真实用户不断建立新长连接）
- 观察各后端 access log 的请求数分布：least_conn 下应明显比轮询更均衡，尤其当某台后端因延迟卡住时，新请求会自动绕开它
验证连接数是否实时反映调度逻辑
开启 stub_status 模块，通过 /nginx_status 查看每台 upstream server 的活跃连接数：
- 对比压测前后 conn_active 值变化，确认 least_conn 确实在选“数字最小”的那个
- 若某台后端连接数持续远高于其他节点，检查是否健康检查未生效（如 max_fails/fail_timeout 未配）、或 keepalive 值过大导致空闲连接占满“账面名额”
