基于JMeter与STOMP协议，构建高并发WebSocket消息推送压测方案
1. 为什么需要WebSocket压测？
想象一下直播平台的弹幕系统：当主播说出一句关键台词时，瞬间会有成千上万条弹幕同时涌向服务器。如果服务器处理能力不足，轻则消息延迟，重则直接崩溃。这就是为什么我们需要对WebSocket服务进行压力测试——提前发现系统瓶颈，避免线上事故。
传统HTTP协议是"一问一答"的短连接，而WebSocket是全双工长连接，测试方法完全不同。我遇到过最典型的坑是：用普通HTTP压测工具测试WebSocket接口，结果连握手阶段都过不去。后来发现必须使用支持WebSocket协议的专用工具，比如JMeter配合插件才能模拟真实场景。
2. 环境准备与插件安装
2.1 JMeter基础配置
首先到Apache JMeter官网下载最新版本（建议5.4.1以上）。解压后进入bin目录，Windows用户双击jmeter.bat，Mac/Linux用户运行jmeter.sh。有个实用小技巧：通过Options → Choose Language → Chinese可以切换中文界面，但对开发者来说保持英文环境更利于排查问题。
2.2 安装WebSocket插件
原生JMeter不支持WebSocket协议，需要安装第三方插件。推荐使用WebSocket Samplers，下载最新jar包后，直接放入jmeter目录下的lib/ext文件夹。重启JMeter后，在取样器列表里能看到这些新组件：
- WebSocket Open Connection：建立连接
- WebSocket Single Write/Read：单次读写
- WebSocket request-response：请求响应组合
注意：如果遇到ClassNotFound错误，可能是依赖冲突。建议先清理lib/ext目录下其他非必要jar包。
3. STOMP协议报文解析
3.1 握手阶段模拟
STOMP协议建立在WebSocket之上，就像HTTP之于TCP。测试Spring Boot的STOMP服务时，握手请求需要包含特定头信息。例如连接教室聊天室的请求：
GET /ws-endpoint/1002 HTTP/1.1 Host: your-server.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Version: 13服务端正确响应应该是HTTP 101状态码，表示协议切换成功。在JMeter中可以用"HTTP请求"组件模拟这个过程，但更推荐直接用WebSocket Open Connection组件自动处理。
3.2 订阅与消息格式
建立连接后，需要发送STOMP指令完成订阅。比如要加入ID为5678的群组：
CONNECT businessId:5 memberId:1002 accept-version:1.1,1.0 heart-beat:10000,10000 ^@这个看似怪异的^@实际上是NULL字符（\u0000），在JMeter中需要原样保留。紧接着发送订阅指令：
SUBSCRIBE businessId:5 memberId:1002 id:sub-1 destination:/topic/5678 ^@4. 构建压测脚本
4.1 线程组配置
右键Test Plan → 添加 → 线程组，关键参数这样设置：
- 线程数：5000（根据机器性能调整）
- Ramp-up时间：60秒（避免瞬间冲击）
- 循环次数：Forever（持续测试）
4.2 连接建立逻辑
计数器配置：添加计数器元件，起始值2000，递增1，引用名设为sessionId。这样每个虚拟用户会有唯一ID。
WebSocket Open Connection：
- 服务器地址：ws://your-server:8080/ws
- 路径参数：/ws/${sessionId}
- Timeout设为30000ms（长连接需要更长时间）
认证与订阅：添加WebSocket Single Write，填入上文STOMP指令模板，注意替换${sessionId}变量。
4.3 消息接收处理
添加三个WebSocket Single Read组件分别处理：
- 握手响应（预期收到"o"）
- 连接确认（预期收到CONNECTED帧）
- 群组消息（Timeout设为300000ms）
实测技巧：在调试阶段可以先用10个线程测试，在"查看结果树"监听器中检查每个步骤的请求响应是否正常。
5. 高并发优化策略
5.1 连接保持方案
原生JMeter的WebSocket组件有个致命缺陷——默认会立即关闭连接。通过修改jmeter.properties文件增加：
ws.connection.timeout=3600 ws.connection.idle.timeout=600或者在测试计划中添加BeanShell定时器，定期发送心跳报文：
vars.put("heartbeat", "\\n^@");5.2 分布式压测
单机受限于端口数（约16000个），需要分布式部署：
- 在所有压力机修改系统配置：
# Linux sysctl -w net.ipv4.ip_local_port_range="1024 65535" sysctl -w fs.file-max=1000000 - 在JMeter主控机修改bin/jmeter.properties：
remote_hosts=192.168.1.101,192.168.1.102 - 启动从机服务：
jmeter-server -Djava.rmi.server.hostname=本机IP
6. 结果分析与常见问题
6.1 关键监控指标
- 连接成功率：低于99%说明握手阶段有问题
- 消息延迟分布：用聚合报告看90%线值
- 服务端资源：重点关注内存和线程数
6.2 典型错误排查
Connection reset异常：
- 检查服务端keepalive配置
- 确认防火墙没有中断长连接
端口耗尽问题：
# Windows查看端口使用 netstat -ano | find "ESTABLISHED" # Linux ss -s内存泄漏迹象： 在JMeter的JVM参数中添加监控：
-JXX:+HeapDumpOnOutOfMemoryError -JXX:HeapDumpPath=/tmp最近一次电商大促前，我们用这套方案成功模拟了20万用户同时在线抢红包的场景。当时发现当连接数超过8万时，服务端的Epoll选择器会出现性能陡降，后来通过调整Linux内核参数解决了问题。压测的价值就在于提前暴露这些隐患，而不是等到真实用户遇到问题时才手忙脚乱。