要实现百万级并发压测，对 LoadRunner 集群的规划、部署和调优都提出了高要求。按照架构规划 - 负载生成器集群搭建 - 系统级优化 - LoadRunner 自身配置优化 - 控制器和监控优化的顺序

一、总体架构

百万级并发不可能靠一两台机器完成，必须采用多控制器加多负载生成器的分布式集群。

推荐方案：使用 LoadRunner Enterprise（原 Performance Center） 作为调度中心，能管理多个 Controller 主机，再将负载分发到成百上千台 Load Generator（LG）。

无 LRE 时的替代方案：用多台独立 Controller，各控制一组 LG，最后人工合并结果。

负载生成器：必须选择 Linux 系统（CentOS/RHEL 7/8），以突破 Windows 在端口数、文件句柄、内存管理上的限制。

网络：LG 到被测系统的总带宽可能高达数十 Gbps，需要万兆光纤网卡、多链路绑定，并保证交换机、防火墙的会话容量足够。

二、负载生成器集群部署和OS级调优

这是整个集群的基础，需要将单台 LG 的 Vuser 容量尽可能榨取。

1. 单台容量估算

经过极致优化的 Linux LG（如 8 核 CPU、16 GB 内存），在 HTTP/HTML 协议、线程方式下，可稳定承载 5000 ~ 10000 个 Vuser。百万并发需要 100 ~ 200 台这样的 LG。

2. 操作系统重要参数调整

以下配置均以 CentOS 7/8 为例，需要写入 /etc/sysctl.conf 并执行 sysctl -p，同时配合 PAM 限制。

文件描述符

每个 Vuser 会占用如果干 socket，必须放开限制。

/etc/security/limits.conf 添加：

text

* soft nofile 1048576

* hard nofile 1048576

root soft nofile 1048576

root hard nofile 1048576

同时执行 ulimit -n 1048576 生效。

本地端口范围

避免因端口不足而无法建立连接。

net.ipv4.ip_local_port_range = 1024 65500

TIME_WAIT 优化

压测时大量短连接会积压 TIME_WAIT，必须快速回收复用。

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_fin_timeout = 30

（注意 tcp_tw_recycle 在高版本内核已废弃，不要使用）

连接队列和 backlog

net.core.somaxconn = 65535

net.ipv4.tcp_max_syn_backlog = 8192

连接追踪表

如果启用 iptables，需调大 conntrack 表，否则连接会被丢弃。

net.netfilter.nf_conntrack_max = 2097152

压测期间建议直接关闭防火墙（systemctl stop firewalld）以减少开销。

内存和交换

降低 swap 倾向，防止内存抖动。

vm.swappiness = 10

网卡队列和多队列

保证网卡 RSS 多队列启用，将软中断均匀分布到多个 CPU 核。如使用 Intel 万兆网卡，可调整中断亲和性。

3. IP 欺骗必备的网络配置

如果要模拟大量不同 IP 访问，必须在每台 LG 上预先绑定大量辅助 IP。

用脚本批量添加：假设网卡为 eth0，创建 eth0:1、eth0:2 …，每个 IP 一个子接口。

需要保证这些 IP 能够和目的系统互通，且路由正确；同时交换机 MAC 表、ARP 表能够承载。

三、LoadRunner配置优化

1. Vuser 运行方式

在 Runtime Settings 中将 Vuser 运行方式设为 线程（Thread），而不是进程。一个进程可跑多个线程，内存消耗大幅降低。

2. 日志级别

将日志设为“仅在出错时记录”甚至完全禁用。日志 IO 是压测时最容易被忽略的短板，尤其在使用 NFS 等远程存储时。

3. HTTP 连接复用

启用 HTTP Keep-Alive 并设置合适的超时，可以让一个 Vuser 复用 TCP 连接发送多个请求，减少握手开销。

Web 协议下的连接池设置：web_set_sockets_option(“INITIAL_BASIC_CONNECTIONS”, “4”) 等，根据目的服务器的 Keep-Alive 能力调整。

4. 思考时间和步速

不要勾选忽略思考时间，否则压力会超过真实业务，且极易打挂服务器。

使用随机百分比，如 80% ~ 120%，让每个 Vuser 的行为有差别，更贴近真实。

如果需严格控制 TPS，可增加 pacing（每次迭代之间的固定延迟）。

5. 参数化文件方法

将 CSV 参数文件放在 LG 本地磁盘（最好是 SSD），避免从 Controller 远程读取。

选择共享或每次迭代更新方式，减少文件加载次数。百万 Vuser 如果每个都打开一次文件，磁盘 IO 会瞬间崩溃。

可使用 LoadRunner 的自动参数化或提前在 LG 上生成好切分后的文件，利用线程号分配。

6. 脚本代码优化

删除所有 lr_output_message、lr_log_message 等打印函数。

减少不必要的 web_reg_find 边界检查（仅保留重点断言）。

避免在 Action 中使用 lr_save_string 等函数创建大量长字符串，注意变量释放。

7. Agent 和服务

在 Linux LG 上，保证 LR Agent 以守护进程方式稳定运行，可使用 m_daemon 或 systemd 管理。增大 Agent 和 Controller 通信的超时时间，防止大量 LG 掉线。

四、控制器和场景调度优化

1. 控制器部署

Controller 机器需独立配置，建议 16 核以上、32 GB 内存，万兆网卡，并单独供电。

如果采用 LRE，可部署多台 Controller 主机分担调度压力，每一台管理数百台 LG。

Controller 和 LG 之间只传输控制指令和少量结果，但连接数也很多，因此需开放 MI Listener 端口（默认 50500）并调整防火墙规则。

2. 场景设计

采用按组逐步加压，如先用 10 万并发运行 5 分钟，确定无异常后再增加下一个 10 万，避免瞬间将目的系统打死，无法分析短板。

启用 IP 欺骗：在场景中勾选该选项，并保证每台 LG 已经配置好相应的 IP 池。

关闭自动排序和自动初始化所有 Vuser，改为手动控制 ramp-up，减少 Controller 瞬时压力。

对于长时间测试，需设置合理的 Duration，并配合逐步退出机制。

3. 结果监控

不要启用过多的实时监控图（如 Windows 资源图、SQL 计数器等），它们在百万并发时会严重拖累 Controller。

将采样间隔拉长（如 5~10 秒），只收集事务响应时间、TPS、错误数等重要数据。

被测系统的资源监控应通过独立的监控工具（如 Zabbix、Prometheus）旁路采集，不要依赖 LoadRunner 的全量监控。

五、执行诊断

阶梯测试：从 1 万-5 万-10 万……逐级递加，每个阶梯运行 10~15 分钟，观察 LG 的 CPU、内存、端口使用率、网络吞吐，以及控制器是不是出现“连接断开”或“超时”报错。

LG 自检命令：在每台 LG 上运行 ss -s 查看 socket 数量，netstat -an|wc -l 查看连接数，nmon 或 top 监控资源，保证端口没有耗尽、内存无泄漏。

错误处理：如果出现大量“连接超时”或“无法绑定 socket”，优先检查 ip_local_port_range 和防火墙 conntrack；如果大量“502/503”，则很可能是被测系统过载，而不是 LG 端问题。

六、总结

百万级并发的 LoadRunner 压测集群不是简单的多机堆叠，而是OS 极限调优加LR 配置裁剪加分布式调度的系统工程。

抓住三个重要：

用大量 Linux LG 并通过内核参数释放网络和文件句柄限制；

将 Vuser 运行开销降到最低（线程方式、零日志、连接复用）；

使用 LoadRunner Enterprise 或合理分治多个 Controller，避免单一调度节点短板。