WebSocket压测必须先确认服务端暴露实时监控指标，否则等于蒙眼开车；需确保输出wsServer.clients.size、upgrade_status_101_count、event_loop_delay_ms等三项核心数据，并使用jmeter-websocket-samplers-1.2.8.jar插件，正确配置连接与响应超时、分阶段建模及关键指标监控。
WebSocket压测必须先确认服务端暴露的监控指标
没接入服务端实时指标的WebSocket压测，等于蒙眼开车。光看JMeter里“成功连接数”没意义——你不知道这些连接是否真被服务端accept()了，还是卡在握手队列、TLS协商或事件循环里。必须确保服务端能输出三项核心数据：wsServer.clients.size（活跃连接数）、upgrade_status_101_count（握手成功率）、event_loop_delay_ms（Node.js）或reactor_busy_time（Swoole）。如果服务端是Java Spring WebSocket，得额外暴露StompBrokerRelayHealthIndicator或自定义Actuator端点。
JMeter插件选1.2.8版，否则采样器埋点失效
用jmeter-websocket-samplers-1.2.8.jar，不是最新版也不是随便下个jar。其他版本（比如1.4.x）会缺失关键埋点，导致云压测平台或Prometheus抓不到websocket_open_duration_ms、ping_timeout_count等指标。安装路径必须是JMETER_HOME/lib/ext/，重启JMeter后，在取样器列表里看到6个以“WebSocket”开头的选项才算生效。特别注意：WebSocket Open Connection采样器里的Connection timeout (ms)建议设为5000，低于3000容易把慢握手误判为失败；而Response timeout (ms)在WebSocket request-response Sampler中应按业务场景设（如聊天类设3000，行情推送可设100）。
线程组不能只堆数量，要模拟真实生命周期
直接设1000线程+0秒Ramp-Up，大概率触发服务端SYN队列溢出或TIME_WAIT风暴。正确做法是分三阶段建模：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 连接建立期：Ramp-Up 120秒，每秒新建约8–10连接，观察
upgrade_status_101_count是否线性上升 - 稳态维持期：保持连接数恒定，用
WebSocket Ping/Pong采样器每15秒发一次心跳，Pong(read)timeout设6000 - 扰动测试期：在第5分钟起，每30秒随机关闭5%连接并立即重建，验证服务端连接池回收是否及时
如果用CSV Data Set Config注入用户ID，记得勾选Recycle on EOF?和Stop thread on EOF?，否则线程会因读空文件卡死。
报告里真正有用的字段就这四个
别被JMeter默认聚合报告里20多个字段带偏。盯紧以下四项，其余全是干扰项：
-
WebSocket Open Connection的90% Line：超过500ms说明TLS或DNS有瓶颈 -
WebSocket request-response Sampler的Error %：持续＞0.5%就要查服务端日志里是否有MaxPayloadSizeExceededException - 监听器
Backend Metrics（需Prometheus+Grafana）中memory_usage_percent是否突破85% - 系统级
netstat -an | grep :80 | wc -l值是否接近net.core.somaxconn设定值
最大承载量不是某个峰值数字，而是“在Error %＜0.3%、90% Line＜300ms、内存占用＜75%前提下，能稳定维持30分钟的最高连接数”。这个数往往比瞬时峰值低20–40%，但才是上线敢用的真实值。
