JMeter分布式压测

一、为什么需要分布式压测

单机压测有一个很现实的问题：

压测机本身也有性能上限。

例如你希望模拟：

5000 并发
2 万 QPS

如果只用一台机器跑 JMeter，可能先把压测机自己的 CPU、内存、网络打满，而不是把被测系统打满。

这时你看到的性能瓶颈，其实是压测机瓶颈，不是业务系统瓶颈。

所以当单机能力不足时，就需要多台机器一起发压，形成 分布式压测。

二、什么是 JMeter 分布式压测

JMeter 分布式压测通常采用：

1 台控制机（master）
N 台施压机（slave）

结构示意：

master
 ├ slave-1
 ├ slave-2
 └ slave-3

控制机负责：

• 分发测试脚本
• 统一启动压测
• 汇总执行结果

施压机负责：

• 实际发请求

三、适合什么场景

分布式压测一般适合以下场景：

• 单机 CPU 已经打满
• 需要更高并发
• 需要更高 QPS
• 需要模拟多区域流量

如果只是：

100 并发
几百 QPS

通常单机已经足够，没必要一开始就上分布式。

四、JMeter 分布式的基本要求

在实际部署前，需要满足几个前提：

1. 所有机器 JMeter 版本一致

否则容易出现脚本兼容问题。

2. 所有机器 Java 版本尽量一致

避免环境差异带来问题。

3. 脚本、CSV、证书等资源保持一致

如果脚本依赖：

• CSV 文件
• 自定义 jar
• 证书文件

这些文件都要同步到每一台施压机。

4. 网络互通

master 必须能访问每一台 slave。

五、分布式部署思路

典型步骤如下：

第一步：准备多台压测机

例如：

master: 192.168.1.10
slave1: 192.168.1.11
slave2: 192.168.1.12

第二步：在每台机器上安装 JMeter

目录尽量保持一致，例如：

/opt/jmeter

第三步：配置 slave

启动每台 slave 上的 JMeter Server。

第四步：在 master 上配置远程主机列表

把所有 slave 地址写入配置文件。

第五步：从 master 发起远程压测

统一启动所有 slave 开始发压。

六、核心配置项

在 jmeter.properties 中，最关键的是：

remote_hosts=192.168.1.11,192.168.1.12

它表示 master 要控制哪些远程施压机。

然后在每台 slave 上启动：

jmeter-server

在 master 上执行：

jmeter -n -t test.jmx -R 192.168.1.11,192.168.1.12 -l result.jtl

含义：

• -n：非 GUI 模式
• -t：测试脚本
• -R：远程施压机列表
• -l：结果文件

七、分布式压测时要关注什么

分布式不是“机器越多越好”，而是要关注每台施压机是否都健康。

重点看：

• 每台施压机 CPU 使用率
• 每台施压机内存使用率
• 每台施压机网络带宽
• 被测系统是否已达到目标流量

例如：

目标 QPS = 10000
实际 QPS = 6000

这时要判断到底是：

• 施压机没打满
• 脚本有限制
• 被测系统已经到瓶颈

八、常见问题

1. slave 启动了，但 master 连不上

常见原因：

• 防火墙未开放
• IP 写错
• 端口不通

2. 远程机器没拿到 CSV 数据

如果脚本使用本地文件：

users.csv

每台 slave 都要有这个文件，而且路径要一致。

3. 结果不稳定

可能原因：

• 某一台施压机性能太差
• 网络抖动
• slave 机器环境不一致

4. GUI 模式做分布式

这通常不是推荐做法。
正式压测应该使用命令行模式。

九、Java 后端同学要特别注意什么

如果你是 Java 后端工程师，做分布式压测时最容易忽略两点：

1. 不要只看 master 的结果文件

还要同时观察：

• 应用服务监控
• JVM 监控
• 数据库监控

2. 不要把施压能力不足误判成系统很稳

如果压测机打不出目标流量，被测系统看起来会“很轻松”，但这是假象。

十、什么时候该考虑 k6、Gatling、专业压测平台

JMeter 分布式很好用，但它不是无限扩展的。

如果你的目标已经是：

• 非常高的 QPS
• 更复杂的云端分布式施压
• 更细粒度的资源控制

那就可以考虑：

• k6
• Gatling
• 专业压测平台

但对于大多数 Java 后端团队来说，JMeter 分布式已经足够覆盖日常接口压测。

十一、总结

JMeter 分布式压测解决的是：

• 单机压不动
• 压测机先到瓶颈
• 目标流量较高

核心思路很简单：

master 控制
slave 发压

真正的关键不在“会不会配置”，而在于你能不能判断：

• 是施压机不够
• 还是被测系统不够

这才是分布式压测的价值所在。