jmeter压测websocket接口不能只靠一个sampler完事；必须拆分使用websocket open connection（建连）、request-response sampler（复用连接发消息）和close connection（统一关连），并勾选streaming connection启用长连接复用，否则高并发下必现连接泄漏、响应错乱与线程阻塞。
直接说结论：jmeter 压测 websocket 接口，**不能只靠一个 websocket sampler 就完事**；高并发下连接泄漏、响应错乱、线程阻塞这三类问题，90% 都出在 sampler 组合方式和连接生命周期管理上。
为什么 WebSocket Open Connection 必须单独存在
很多人把连接、发消息、关连接全塞进一个 WebSocket Sampler，结果一开 200 线程就报 java.lang.OutOfMemoryError: unable to create new native thread。根本原因在于：这个 sampler 默认是“一次性会话”——它建立连接 → 发送数据 → 等响应 → 关闭连接，全程阻塞当前线程。线程数上去后，大量连接在关闭前卡在响应等待里，资源不释放，最终压垮本机。
正确做法是拆开控制：
-
WebSocket Open Connection放在线程初始化阶段（比如放在setUp Thread Group或线程组第一个 sampler），只负责建连，不发业务数据 - 后续所有发消息操作（
WebSocket Request-Response Sampler或WebSocket Single Write Sampler）必须勾选Use existing connection，复用已建连接 - 连接关闭统一由
WebSocket Close Connection承担，且建议放在tearDown Thread Group中，避免主线程组异常中断导致连接残留 - 如果要模拟“连接后长期保活+心跳”，不要用循环发消息去硬扛，而应启用
WebSocket Ping/Pong Sampler，它底层调用的是标准 WebSocket 控制帧，不会干扰业务数据流
Streaming Connection 勾与不勾的实际影响
这个选项藏在 WebSocket Sampler 的基础配置里，但它的行为和直觉相反：勾上 ≠ 更“流式”，而是强制开启长连接模式；不勾 = 每次请求都新建+立即关闭 TCP 连接 —— 这已经不是 WebSocket 测试，退化成 HTTP 轮询了。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
关键差异：
- 勾选后，连接对象被缓存在线程本地（
ThreadLocal），后续同一线程的 sampler 可复用；不勾选则每次创建新连接，握手开销翻倍，且无法验证服务端推送能力 - 勾选后，若未显式调用
Close Connection，连接会一直挂在线程结束时才由 JVM 回收 —— 这就是连接泄漏的主因 - JMeter 5.4+ 版本中，该选项对
wss协议影响更大：不勾选时 SSL 握手可能失败，报javax.net.ssl.SSLHandshakeException
并发量上不去？先检查这三处硬限制
设了 1000 线程，实际只建了 300 条连接，日志里反复出现 Connection refused 或 Timeout occurred while waiting for response，大概率不是服务端问题，而是本地资源卡死了：
-
max file descriptors：Linux 系统默认单进程最多打开 1024 个文件句柄，每个 WebSocket 连接至少占 2 个（socket + SSL context），1000 并发需至少 3000+ 句柄。执行ulimit -n 65536再启动 JMeter - JVM 堆外内存：WebSocket 插件（尤其是 Peter Doornbosch 1.2.8 版）大量使用
DirectByteBuffer缓冲区，默认不受-Xmx管控。建议启动时加-XX:MaxDirectMemorySize=2g - 插件版本兼容性：2026 年主流环境（JMeter 5.6 / Java 17）下，仅
jmeter-websocket-samplers-1.2.8.jar被验证稳定；用旧版（如 1.0.2）或 GitHub 上非官方 fork，大概率在 500+ 并发时触发IllegalStateException: channel not open
最易被忽略的一点：WebSocket 压测不是比谁线程数设得高，而是比谁能把“连接建立成功率 × 消息收发稳定性 × 连接持续时长”这三个变量同时拉满。很多团队卡在 800 并发就崩，回头发现只是忘了在 WebSocket Open Connection 里把 Connection Timeout 从默认 5000ms 改成 15000ms —— 服务端 TLS 握手慢了 200ms，JMeter 就直接判连接失败，后续全部 sampler 全部跳过。
