测试Nginx多实例集群横向扩展能力，核心是验证并发上升时增实例能否线性提升QPS、降低p95延迟并保持稳定；需对比不同实例数下的吞吐增幅比、延迟分布、资源饱和点及错误归因，避免单机瓶颈或共享资源争用干扰。
测试 Nginx 多实例集群的横向扩展能力，核心是验证：当并发请求量上升时，增加 Nginx 实例数能否线性提升整体吞吐（QPS）、降低平均延迟，并保持系统稳定。不能只压单台，也不能只看 CPU 利用率——要测“加机器是否真有用”。
明确测试目标与关键指标
横向扩展能力不是“能不能跑”，而是“加 1 台 vs 加 4 台，QPS 是否接近 4 倍、95% 延迟是否不劣化”。必须盯紧以下几项：
- 吞吐量（QPS/TPS）：单位时间成功响应请求数，对比不同实例数下的绝对值和增幅比
- 延迟分布：重点关注 p50/p95/p99，尤其 p95 是否随实例扩容明显下降或持平
-
资源饱和点：观察每台 Nginx 的 CPU 使用率、连接数（
active connections）、内存 RSS，确认瓶颈是否从单机转移到负载均衡层或后端服务 -
错误率：5xx（尤其是 502/503）、超时、连接拒绝（
connection refused或reset by peer）需归因——是上游 LB 转发异常？还是后端过载反压？
搭建可复现的测试环境
避免干扰项，让结果反映真实扩展性：
- 所有 Nginx 实例使用完全相同的配置（含 worker 进程数、keepalive、buffer 大小、日志关闭），仅调整
upstream中 server 列表 - 前置负载均衡器（如另一台 Nginx 或 HAProxy）开启 consistent hashing 或 least_conn，禁用 session stickiness（除非业务强依赖）
- 后端服务用轻量模拟器（如
gunicorn + Flask返回固定 JSON），确保其本身不成为瓶颈；或用mockserver固定响应时间（如 20ms） - 压测客户端与被测集群隔离部署（至少跨物理机或不同可用区），禁用本地 DNS 缓存，直连 VIP 或后端 IP
分阶段压测与对比方法
不追求一次打满，而要刻画“规模-性能”曲线：
- 基线测试：1 台 Nginx 实例，逐步加压（如 1k→5k→10k 并发），记录 QPS、延迟拐点、错误突增点
- 等比例扩容测试：保持总并发不变，分别测试 2/4/8 台实例（每台承担约 1/2/1/4 的连接），看 QPS 是否同比例提升、p95 是否下降
- 固定单机压力测试：设定每台 Nginx 承载相同并发（如每台 2k 连接），再叠加实例数（2台=4k总并发，4台=8k总并发…），观察整体吞吐是否线性增长
-
长稳测试（30+ 分钟）：在目标负载下持续运行，检查内存泄漏（RSS 持续上涨）、连接堆积（
netstat -ant | grep :80 | wc -l）、TIME_WAIT 累积
定位非线性瓶颈的常见线索
如果 QPS 增幅远低于实例增幅，大概率存在隐性串行点：
- 共享资源争用：DNS 解析未启用 resolver cache、SSL 会话复用未配 shared cache、access_log 写入同一块磁盘
-
上游 LB 成为瓶颈：单点 Nginx 做七层转发时，worker 进程不足或
epoll事件处理不过来；改用四层（IPVS/LVS）或升级到多进程 LB - 后端服务未水平扩展：Nginx 加了 4 台，但 upstream 指向的只有 1 台 Tomcat——此时瓶颈永远在后端
-
内核参数限制：单机
net.core.somaxconn、fs.file-max、net.ipv4.ip_local_port_range不足，导致新建连接失败
