简介：这是一份面向性能测试工程师与消息中间件运维人员的RabbitMQ压测实践资源，基于Apache JMeter搭建，用于评估RabbitMQ在高并发场景下的生产与消费性能。资源包共2881个文件，约53.02MB，以1510个html、482个png、271个js等JMeter界面与文档资源为主，同时包含82个jar依赖、55个jmx测试计划、58个lang语言包及少量csv、properties配置，覆盖插件运行、脚本编写与结果展示所需组件。已有1854人学习下载。借助其中的jmx测试计划与BeanShell脚本，读者可快速搭建生产者、消费者线程组，结合聚合报告、响应时间图等监听器采集吞吐量、响应时间与错误率，并通过CSV参数化和分布式部署模拟大规模并发，为RabbitMQ队列、交换机调优提供数据支撑。
1. 从一份压测包说起：JMeter 怎么把消息压进 RabbitMQ
很多团队做消息队列压测时，第一反应是写个 Java 程序循环发消息，跑完看日志。这种做法能出数，但改一个并发梯度就要重新编译，换一个队列又要改代码，压测报告还得自己拼。apache-jmeter-rabbitMQ测试.zip这类资源包解决的正是这个痛点：用 JMeter 的可视化线程组、参数化配置和聚合报告，把 RabbitMQ 的生产与消费压测变成一份可复用、可调参、可出图的测试计划。它适合两类人：一是后端或中间件工程师，需要验证某个队列在目标并发下的吞吐与延迟；二是测试工程师，要把 MQ 压测纳入持续集成的常规环节。核心思路不复杂——JMeter 本身不原生支持 AMQP，需要借助 AMQP 插件把「发消息」和「收消息」变成采样器，再交给线程组调度。下面按「环境怎么搭、脚本怎么写、参数怎么调、坑在哪」的顺序拆开讲。
2. 环境搭建与 AMQP 插件选型：为什么不能直接连
2.1 JMeter 原生能力边界与插件方案
JMeter 的标准采样器覆盖 HTTP、JDBC、JMS 等协议，但 AMQP 0-9-1（RabbitMQ 使用的协议）不在其中。JMS 采样器理论上可以对接部分消息中间件，但 RabbitMQ 的 JMS 支持需要额外开启插件且行为与原生 AMQP 有差异，压测结果容易失真。常见做法是安装第三方 AMQP 插件，它提供两个核心元件：AMQP Publisher（生产者采样器）和 AMQP Consumer（消费者采样器），底层基于 RabbitMQ 官方 Java 客户端。选型时要确认插件版本与 JMeter 大版本匹配，插件放错目录会导致启动后菜单里根本找不到元件，这是新手最容易翻车的第一步。
2.2 插件安装与依赖放置的完整步骤
安装分三步：下载插件 jar 包、放入 JMeter 的 lib/ext 目录、重启 JMeter。如果插件依赖额外的客户端库，也要一并放入 lib 目录。下面用命令行演示目录结构和校验方式。
# 假设 JMeter 解压目录为 /opt/jmeter # 1. 查看当前 lib/ext 下已有的插件，确认没有旧版本冲突 ls -l /opt/jmeter/lib/ext/ | grep -i amqp # 2. 将下载的 AMQP 插件 jar 放入 lib/ext cp jmeter-amqp-plugin.jar /opt/jmeter/lib/ext/ # 3. 若插件依赖 RabbitMQ Java 客户端，放入 lib 目录 cp amqp-client-5.x.x.jar /opt/jmeter/lib/ # 4. 重启 JMeter，检查插件是否加载 /opt/jmeter/bin/jmeter -v逻辑说明：lib/ext 是 JMeter 加载扩展元件的目录，放这里才能在 GUI 的「添加 → 采样器」里看到 AMQP Publisher。lib 目录放运行时依赖，客户端库放错位置会报 ClassNotFoundException。参数说明：amqp-client的版本要与 RabbitMQ 服务端版本保持兼容，服务端是 3.x 系列时客户端不宜跨太大版本；JMeter 启动参数-v只打印版本，用于确认程序本身能跑起来，插件是否生效还要进 GUI 看菜单。
2.3 连接参数与虚拟用户数的对应关系
插件装好后，第一个要填的是连接信息：主机、端口、虚拟主机、用户名、密码。这里有个容易忽略的点——JMeter 的每个线程默认独立建立连接，线程数等于连接数。如果设 500 线程，就是 500 条 TCP 连接同时打到 RabbitMQ，服务端的文件描述符和内存会先于队列本身成为瓶颈。我一般会先用 50 线程跑通，再按梯度往上加，同时观察服务端的连接数指标。虚拟主机（vhost）要和生产环境一致，否则队列名对不上，采样器直接报 404 类错误。
3. 生产者压测脚本：从线程组到聚合报告的落地
3.1 线程组参数怎么设才不误导结论
线程组是压测的调度核心，三个参数决定结果的可信度：线程数（并发用户）、Ramp-Up 时间（多久把线程拉满）、循环次数。常见误区是把 Ramp-Up 设成 1 秒、线程数设 1000，结果前 100 毫秒系统被打爆，后面全是超时，你拿到的是「崩溃曲线」而不是「容量曲线」。稳妥做法是 Ramp-Up 设为线程数的 1 到 2 倍秒数，让压力平滑上升，观察吞吐随并发变化的拐点。循环次数建议勾选「永远」配合调度器定时长，或者设一个足够大的固定值，避免线程提前退出导致统计样本不足。
3.2 AMQP Publisher 采样器的关键字段
生产者采样器的配置项里，真正影响压测语义的是这几项：Exchange 名称、Routing Key、队列名、消息体、消息属性。如果只测队列本身的写入能力，可以留空 Exchange，直接指定队列名，走默认交换机。消息体建议用变量或函数生成，避免所有消息完全一样导致服务端做重复优化。下面给一个用 JMeter 函数生成唯一消息体的配置示例。
队列名: bench_queue 消息体: {"seq":"${__counter(FALSE)}","ts":"${__time()}"} 消息属性: deliveryMode=2 持久化: 开启逻辑说明：__counter生成递增序号，__time生成毫秒时间戳，两者组合保证每条消息体不同，更接近真实业务。参数说明：deliveryMode=2 表示持久化消息，会触发磁盘写入，吞吐会明显低于非持久化；如果压测目标是「极限吞吐」，可以先关持久化拿到上限值，再开持久化对比差距。这一步的对比数据往往比单一数字更有说服力。
3.3 用聚合报告和断言判断压测是否有效
压测跑完不能只看 Throughput 一个数。聚合报告里的平均值、中位数、90% 线、99% 线、最大值要一起看：如果 99% 线远高于中位数，说明存在长尾延迟，通常是服务端刷盘或流控触发。还要加响应断言，确认采样器返回的是成功而不是被吞掉的异常。下面是一个判断脚本是否有效的检查清单式命令，用 JMeter 非 GUI 模式跑并输出结果文件。
# 非 GUI 模式执行测试计划，结果写入 result.jtl /opt/jmeter/bin/jmeter -n \ -t rabbitmq_producer.jmx \ -l result.jtl \ -e -o report_output # 查看结果文件中的错误率 awk -F',' 'NR>1 && $8!="200" {err++} END {print "error samples:", err+0}' result.jtl逻辑说明：-n是非 GUI 模式，适合压测机没有图形界面的场景；-l指定原始结果文件；-e -o生成 HTML 报告。参数说明：结果文件里的成功标记取决于采样器实现，有的版本用 200，有的用 true，跑之前先用小样本确认字段含义，别拿错列做统计。这一步的 awk 只是快速粗筛，正式分析还是看 HTML 报告里的百分位表。
4. 消费者压测与端到端链路验证
4.1 消费者采样器的预取与确认模式
只压生产者只能说明「写得进」，说明不了「消费得动」。消费者采样器要关注两个参数：预取数量（prefetch count）和自动确认（autoAck）。预取数量决定每个消费者一次拉多少条消息到本地缓冲，设太大内存涨得快，设太小吞吐上不去，常见起点是 100 到 300 之间调。自动确认设为 true 时，消息一投递就标记删除，压测吞吐好看但会掩盖消费失败；设为 false 则要显式确认，更接近生产语义，但脚本里要处理确认逻辑。我一般先用自动确认拿吞吐上限，再用手动确认拿真实处理能力，两组数据对照着看。
4.2 端到端延迟的测量方法
端到端延迟是「消息发出到被消费」的时间差。做法是在消息体里带一个发送时间戳，消费者采样器收到后解析出来，用当前时间减去它，再通过 JMeter 的响应断言或后置处理器把差值写进结果。下面用 JSR223 后置处理器演示计算逻辑。
// 从响应数据中取出消息体，解析发送时间戳 def body = prev.getResponseDataAsString() def sendTs = new groovy.json.JsonSlurper().parseText(body).ts as long def now = System.currentTimeMillis() def latency = now - sendTs // 写入变量，供聚合报告或断言使用 vars.put("e2e_latency", latency.toString()) // 同时标记采样器成功 prev.setSuccessful(true)逻辑说明：prev是当前采样器结果对象，getResponseDataAsString拿到消息体，解析出 ts 字段后与当前时间相减。参数说明：这个延迟包含网络传输、服务端排队、消费者拉取三段，如果只想看服务端排队时间，需要把发送和消费放在同一台机器上减少网络抖动。vars.put写入的变量可以在后续的聚合报告里通过自定义列引用，也可以在调试采样器里打印出来核对。
4.3 用表格对比不同参数组合的结果
压测的价值在于对比，不是单点数字。下面这张表是我常用的记录格式，把几组关键参数和结果放在一起，方便判断瓶颈在哪。
| 场景 | 线程数 | 持久化 | 预取数 | 吞吐(msg/s) | 99%延迟(ms) |
|---|---|---|---|---|---|
| 基线 | 50 | 否 | 100 | 待填 | 待填 |
| 高并发 | 200 | 否 | 100 | 待填 | 待填 |
| 持久化 | 50 | 是 | 100 | 待填 | 待填 |
| 大预取 | 50 | 是 | 500 | 待填 | 待填 |
表格里的「待填」要在自己环境跑出来后替换。判断逻辑：如果高并发组吞吐不升反降、99% 线飙升，瓶颈在服务端连接或磁盘；如果持久化组吞吐断崖式下跌，瓶颈在刷盘；如果大预取组吞吐略升但延迟也升，说明预取换来了吞吐但牺牲了实时性。
5. 避坑与排查：压测结果不可信的五个原因
5.1 压测机自身成为瓶颈
现象：线程数加到 300 以后吞吐不再增长，CPU 却先到 100%。原因：JMeter 本身是 Java 应用，每个线程都有内存开销，压测机 CPU 或内存先耗尽。解决：用非 GUI 模式跑，关闭监听器里的「查看结果树」，压测机和被测服务分开部署，必要时用多台压测机分布式压测。
5.2 连接未复用导致端口耗尽
现象：跑几分钟后开始大量报连接超时，服务端连接数暴涨。原因：采样器每次请求都新建连接，没有复用。解决：确认插件是否支持连接池或长连接配置，把连接建立放在 setUp 线程组里，或者降低线程数、提高单线程循环次数。
5.3 队列未声明导致消息被丢弃
现象：生产者显示成功，消费者一条都收不到。原因：消息发到了不存在的交换机或路由键不匹配，被静默丢弃。解决：压测前用管理界面确认队列已声明且绑定关系正确，生产者采样器里开启 mandatory 标志，让不可路由的消息返回错误而不是被吞。
5.4 结果文件字段理解错误
现象：统计出来的错误率高得离谱，但服务端日志正常。原因：把结果文件里某一列的值当成了成功标记，实际那一列是别的含义。解决：先用 10 条样本跑一次，打开结果文件逐列核对，确认成功标记列后再写统计脚本。
5.5 忽略服务端流控和内存告警
现象：压测中途吞吐骤降，之后恢复，反复波动。原因：RabbitMQ 触发内存或磁盘流控，暂停接收新消息。解决：压测期间同步监控服务端的内存、磁盘和连接数指标，把流控发生的时间点和吞吐曲线对齐，才能解释波动。
6. 把压测脚本变成可复用的容量基线
压测脚本写完不是终点，能反复用、能对比才有价值。我的习惯是把测试计划里的连接信息、队列名、线程数全部抽成用户定义变量，放在一个单独的配置元件里，换环境只改这一处。然后用命令行参数覆盖变量，让同一份 jmx 文件适配不同环境。下面演示用-J参数覆盖变量的写法。
# 测试计划里用 ${__P(host,localhost)} 引用变量 /opt/jmeter/bin/jmeter -n \ -t rabbitmq_producer.jmx \ -Jhost=192.0.2.10 \ -Jthreads=100 \ -Jqueue=bench_queue \ -l result_$(date +%Y%m%d_%H%M).jtl逻辑说明：__P函数优先读命令行传入的-J参数，没有则用默认值。这样同一份脚本可以在本地、测试环境、预发环境复用，结果文件带时间戳避免覆盖。参数说明：-J是 JMeter 属性，和-G的区别在于作用范围，单机压测用-J就够。跑完把结果文件和当时的参数记录在一起，下次对比时才知道差异来自代码还是来自参数。
再进一步，可以把这套流程接进持续集成：每次服务端版本变更后自动跑一轮基线压测，把吞吐和 99% 延迟写进构建产物，超过阈值就告警。这样容量问题在上线前就能暴露，而不是等线上流量涨上来才发现。我踩过最深的坑是早期只压生产者不压消费者，上线后才发现消费端预取设置不合理导致消息积压，后来把端到端延迟纳入常规压测项才堵住这个口子。希望帮到你。
本文还有配套的精品资源，点击获取
