分布式压测用于突破单台机器的 CPU、内存和网络 I/O 瓶颈。JMeter 采用 Master–Slave 架构：Master 控制机负责分发脚本、下发指令、聚合结果；Slave 执行机以非 GUI 模式运行 jmeter-server，实际产生负载并回传采样结果。

第一阶段：单机压测，先把基础流程跑通

在搭建集群前，必须先在单机完成一次可用压测，确认 JMeter、脚本和目标系统都正常。

1. 环境准备

JMeter 依赖 Java 运行环境，推荐 JDK 8 或 JDK 11，并保证后续集群节点使用相同主版本。安装后配置 JAVA_HOME，把 %JAVA_HOME%\bin 加入 PATH。下载 JMeter 二进制包并解压即可；Windows 运行 bin/jmeter.bat，Linux/Mac 运行 sh bin/jmeter.sh 启动 GUI。

2. 最小可用测试计划

一个单机压测脚本至少包含三层。

线程组：右键测试计划-添加-线程（用户）-线程组。关键参数包括线程数、Ramp-Up 时间和循环次数或调度器时长。Ramp-Up 用于避免所有线程瞬间启动造成冲击。

取样器：在线程组下添加HTTP请求，填写协议、服务器名、端口、路径和方法。

监听器：正式压测至少添加聚合报告，关注 90%/95% 响应时间、错误率和吞吐量。调试阶段可临时添加察看结果树，正式执行前关闭，避免监听器消耗Master资源。

3. 判断单机是否已成为瓶颈

运行后观察聚合报告。如果在预期并发下，JMeter 所在机器 CPU 持续接近或超过 80%，或进程出现明显 GC 压力，而目标系统资源仍未打满，说明单机 JMeter 已成为瓶颈，此时才需要进入分布式阶段。

第二阶段：理解分布式架构的协作方式

动手配置前，需要明确几个容易混淆的行为。

Master 建议不产生负载。Master 只负责管理测试流程和汇总结果。技术上可以让 Master 也作为 Slave 参与压测，在 remote_hosts 中加入自身 IP 即可，但建议将控制逻辑与负载生成分离，否则控制线程和压测线程争抢资源，采样数据容易失真。

线程数是每台 Slave 各自的。在 Master 上设置线程数为 100、Slave 数量为 3，总并发为 100 × 3 = 300，而不是 100。Master 会把同一个测试计划完整分发到每台 Slave，每台 Slave 独立执行全部线程。

脚本会自动分发，但参数化文件不会。Master 会把 .jmx 脚本发送到各 Slave，但 CSV 数据文件、依赖 JAR、插件等资源必须预先手动同步到每一台 Slave 的对应路径，否则 Slave 执行时会因找不到文件而报错。

通信基于RMI。Master与Slave 之间通过 Java RMI通信，默认使用 1099 端口。JMeter 4.0 起默认要求 RMI over SSL，在内网可控环境中通常直接禁用 SSL 以简化配置；若走 SSL 路线，则需要生成 rmi_keystore.jks 并分发到所有节点。

第三阶段：集群搭建，逐步配置

1. 前置约束：版本与网络

所有节点必须使用完全相同版本的 JMeter 和相同主版本的 JDK。混用版本会导致脚本解析失败、序列化异常或远程连接被拒绝。节点之间需处于同一局域网或低延迟内网，能够互相 ping 通。如果使用云环境，安全组和防火墙需放通 RMI 端口及动态回调端口。

2. Slave端配置

在每台 Slave 的 bin/jmeter.properties 或 user.properties 中设置：

properties

server.rmi.ssl.disable=true

server_port=1099

server.rmi.localport=1099

server.rmi.ssl.disable=true 

用于绕过自签名证书信任问题。server_port 和 server.rmi.localport 将 RMI 通信固定到 1099，避免 JVM 动态分配端口后被防火墙拦截。

启动 Slave 时必须显式绑定 Slave 的可路由 IP，否则 Slave 可能将 RMI stub 注册到 127.0.0.1，导致 Master 无法连接：

bash

./jmeter-server -Djava.rmi.server.hostname=<Slave_IP>

例如：

bash

sudo ./jmeter-server -Djava.rmi.server.hostname=192.168.1.101

启动成功后终端会显示远程对象已创建。建议使用 nohup 或系统服务方式后台运行。

3. Master端配置

在 Master 的 bin/jmeter.properties 中，同样设置：

properties

server.rmi.ssl.disable=true

并将 remote_hosts 指向所有 Slave 的可路由 IP 与端口：

properties

remote_hosts=192.168.1.101:1099,192.168.1.102:1099,192.168.1.103:1099

多个Slave用英文逗号分隔，不要留空格。配置完成后，先在Master上用telnet <Slave_IP> 1099验证端口可达，再执行实际压测。

4. 执行分布式压测

命令行模式推荐用于正式压测：

bash

./jmeter -n -t /path/to/test_plan.jmx \

  -R 192.168.1.101,192.168.1.102,192.168.1.103 \

  -l /path/to/result.jtl \

  -j /path/to/jmeter.log \

  -e -o /path/to/report

其中-n为非GUI模式；-R指定Slave列表；-l 保存聚合结果；-j 指定日志；-e -o 在测试结束后生成 HTML 报告。如果remote_hosts已在配置文件中写全，也可以用 -r代替-R，自动读取配置中的所有Slave。

GUI模式下的运行-远程启动全部适合调试连接和快速验证，但正式压测应坚持命令行模式，避免Master的GUI资源开销干扰测试。

常见问题

Slave 启动后 Master 连不上，报 Connection refused。大概率原因是 Slave 将 RMI 绑定到了 127.0.0.1，而不是可路由 IP。处理方式是启动时加 -Djava.rmi.server.hostname=<Slave_IP>，并检查 rmi.server.hostname 配置。

连接被拒绝或握手失败。常见原因是 JMeter 4.0+ 默认启用 RMI SSL，但未生成或分发 keystore。内网环境可设置 server.rmi.ssl.disable=true；或执行 create-rmi-keystore.sh 并分发 rmi_keystore.jks。

Master 启动测试后卡住不结束。常见原因是防火墙只放通了 1099，动态 RMI 回调端口被拦截。处理方式是固定 client.rmi.localport 和 server.rmi.localport，并在防火墙中放通。

Slave 报文件找不到或数据重复。常见原因是 CSV 等参数化文件未同步到各 Slave，或所有 Slave 读取同一批数据行。应将数据文件分发到各 Slave 的相同路径；需要唯一数据时结合 __threadNum、__machineName 或外部数据源分配。

脚本在 Master 能跑，Slave 报 ClassNotFound。常见原因是 Slave 缺少 Master 上安装的插件或自定义 JAR。需要同步 lib/ 和 lib/ext/ 中的依赖到所有 Slave。

结果聚合出现数据丢失。常见原因是网络抖动或结果写入未及时刷新。可设置 jmeter.save.saveservice.autoflush=true 强制刷新，并用 -e -o 生成 HTML 报告交叉验证。

分布式压测的复杂度不在JMeter本身，而在版本一致性、RMI端口与IP绑定、资源文件同步这三件事上。单机阶段把脚本和指标跑通，集群阶段严格对齐每一台节点的JDK/JMeter版本、jmeter.properties配置和依赖文件，绝大多数连不上、跑不通、结果不对的问题都可以提前消除。