1. 项目概述为什么我们需要用JMeter测试WebSocket接口如果你是一名软件测试工程师尤其是在2024年这个节点还在用Postman或者HttpClient去“模拟”那些需要实时双向通信的应用比如在线聊天、股票行情推送、协同编辑文档那你可能已经落后了。WebSocket协议早已不是新鲜事物它支撑着我们日常使用的许多“即时”功能。然而测试它却成了一个不大不小的痛点。传统的HTTP测试工具对此束手无策而专门的压力测试工具又往往过于笨重或昂贵。这就是为什么我们需要把目光投向JMeter。作为一个开源、免费且功能强大的性能测试工具JMeter早已超越了单纯的HTTP测试。通过扩展插件它能完美支持WebSocket协议测试。这不仅仅是为了“测通”一个接口更是为了评估在高并发、长连接、持续消息推送的真实场景下你的服务端能否扛得住压力连接会不会异常断开消息顺序和延迟是否符合预期。我见过太多项目功能测试时WebSocket跑得好好的一上线用户量上来连接池爆满、内存泄漏、消息堆积的问题全出来了。所以掌握用JMeter测试WebSocket不是一项炫技而是一个保障服务稳定性的必备技能。接下来我会带你从零开始拆解整个流程包括那些官方文档不会告诉你的坑和技巧。2. 核心工具准备与环境搭建工欲善其事必先利其器。用JMeter测试WebSocket第一步不是写脚本而是准备好正确的“武器库”。这里最大的坑就是依赖包版本不匹配会导致各种莫名其妙的错误。2.1 JMeter本体与WebSocket插件的选择首先你需要一个JMeter。直接从 Apache JMeter官网 下载最新稳定版即可。我建议使用5.5或以上版本对Java的兼容性更好。确保你的系统已安装JDK 8或11推荐LTS版本。核心在于WebSocket插件。历史上主要有两个流行的插件JMeter WebSocket Sampler (by maciejzaleski)这是最经典、资料最多的插件。但它的GitHub仓库已存档最后更新是2016年依赖于较老的Jetty 9.x客户端库。JMeter WebSocket Samplers (by dzharii)这是一个维护更活跃的插件集功能也更丰富支持不同的WebSocket实现。对于大多数入门和常规测试我推荐从经典插件maciejzaleski版开始。虽然它老但稳定社区解决方案多踩坑了也容易找到答案。我们主要使用它。注意直接从某些博客提供的网盘或CSDN链接下载打包的JAR文件存在安全风险且版本可能过时。最稳妥的方式是从GitHub Releases页面下载。2.2 依赖JAR包的“全家桶”式安装与避坑指南这是整个搭建过程中最容易出错的一步。经典插件JMeterWebSocketSampler-1.0.2-SNAPSHOT.jar本身只是一个采样器它需要一组Jetty的WebSocket客户端库才能工作。你需要准备的JAR包清单如下JMeterWebSocketSampler-1.0.2-SNAPSHOT.jar(主插件)jetty-http-9.x.x.jarjetty-io-9.x.x.jarjetty-util-9.x.x.jarwebsocket-api-9.x.x.jarwebsocket-client-9.x.x.jarwebsocket-common-9.x.x.jar实操步骤下载插件访问 JMeter-WebSocketSampler的GitHub Release页面 下载最新的-jar-with-dependencies.jar文件。例如JMeterWebSocketSampler-1.0.2-SNAPSHOT-jar-with-dependencies.jar。这个文件通常已经包含了所有必要的依赖。放置JAR包将下载好的这个“全家桶”JAR文件复制到你的JMeter安装目录下的lib/ext/文件夹中。这是唯一需要放的位置。清理冲突如果lib/ext/目录下存在之前单独下载的、版本不一致的Jetty相关JAR包如jetty-http-9.1.2.v20140210.jar等请务必删除它们。多个版本共存是导致ClassNotFoundException或NoSuchMethodError的罪魁祸首。重启JMeter完成复制后完全关闭并重新启动JMeter GUI。验证安装成功重启后在测试计划上右键选择添加-取样器如果你在列表中看到了“WebSocket Sampler”和“WebSocket Open Connection”等选项恭喜你插件安装成功。避坑心得我强烈反对从各种博客的云盘链接下载零散的JAR包合集。原因有三第一安全性无法保证第二版本可能混杂第三一旦出现问题排查范围太大。直接使用官方Release的-with-dependencies包是最干净、最可靠的方式。如果网络访问GitHub困难可以尝试使用可靠的国内镜像站但务必核对文件哈希值。3. WebSocket Sampler 核心参数深度解析安装好插件后我们来深入理解这个“WebSocket Sampler”采样器里的每一个参数。知其然更要知其所以然这能让你在复杂场景下游刃有余。3.1 连接配置Server、Port与Timeout双击打开一个WebSocket Sampler首先看到的是连接配置部分。Server Name or IP目标服务器的地址。这里可以填域名如echo.websocket.org或IP地址。注意如果后端服务有多个实例并通过负载均衡暴露这里应填写负载均衡器的地址。Port Number端口。WebSocket通常使用ws对应80端口wss(WebSocket Secure) 对应443端口。但很多开发环境会使用如8080、8888等非标准端口务必与开发确认。Timeout: Connection ResponseConnection Timeout建立TCP连接的超时时间。默认5000毫秒。在测试内网服务或压测初期可以适当调低如2000ms以快速失败。如果测试公网服务或网络不稳定可以调高。Response Timeout等待服务器响应的超时时间。默认20000毫秒。这是关键对于长连接、服务器主动推送的场景这个值需要设置得非常大比如300000ms即5分钟否则JMeter会在等待第一条推送消息时就超时。你需要根据业务逻辑来设定。3.2 请求配置Implementation、Protocol与Streaming ConnectionImplementation固定为RFC6455这是WebSocket的现行协议标准无需改动。Protocol选择ws或wss。wss表示基于TLS/SSL的加密WebSocket连接相当于HTTP和HTTPS的关系。如果服务器使用了自签名证书JMeter可能需要额外配置才能跳过证书验证通常不建议在生产压测中跳过。Streaming Connection这是理解WebSocket测试逻辑的核心复选框。勾选表示此采样器希望复用已有的WebSocket连接。如果存在一个活跃的连接它就不会创建新连接而是直接在该连接上发送消息。用于模拟在一个会话内发送多条消息的客户端行为。不勾选表示此采样器在发送消息前会建立一条全新的WebSocket连接并在收到响应后根据配置立即关闭。用于模拟“发一条消息就断开”的短连接场景。3.3 请求与响应模式Request Data与Pattern匹配Request Data你要发送给服务器的消息内容。可以是纯文本如{type:ping}、二进制数据需编码等。这里支持JMeter变量例如${message}便于参数化。Response Pattern期待响应模式。JMeter会持续监听连接直到从服务器收到的消息中包含这里设置的模式字符串才会将此采样器标记为“成功”并继续执行下一个采样器如果Streaming Connection开启。例如你发送一个登录请求服务器会返回login_success那么你可以将Response Pattern设为login_success。如果留空JMeter会在收到任何一条消息后立即认为成功。Close Connection Pattern关闭连接模式。如果服务器返回的消息中包含此模式字符串JMeter会主动关闭当前WebSocket连接。例如服务器返回error: invalid_token时触发连接关闭。这个功能对于测试服务器的异常断开逻辑非常有用。Message Backlog消息回溯数量。它定义了在“查看结果树”等监听器中最多显示多少条从服务器接收到的历史消息。默认是3。如果你在一个长连接中接收了10条推送消息设为3就只显示最后3条。在调试时可以将其设大以便查看完整交互。4. 从零构建一个完整的WebSocket测试计划理论说再多不如动手跑一遍。我们来构建一个测试计划模拟一个简单的“心跳检测消息收发”场景。4.1 测试场景设计假设我们有一个WebSocket服务连接地址ws://localhost:8080/ws行为客户端连接后需要先发送一个认证消息{auth: token123}服务器返回{status: ok}表示成功。认证成功后客户端每隔10秒发送一个心跳{type: ping}服务器回复{type: pong}。同时客户端可以随时发送聊天消息{type: chat, content: hello}服务器会广播或回显。我们的测试计划将模拟建立连接 - 认证 - 发送心跳 - 发送聊天消息 - 关闭连接。4.2 测试计划结构搭建创建测试计划打开JMeter默认有一个“测试计划”。将其重命名为“WebSocket全流程测试”。添加线程组右键测试计划 -添加-线程(用户)-线程组。设置线程数用户数为1循环次数为1。我们先单用户调试。添加配置元件右键线程组 -添加-配置元件-HTTP请求默认值。虽然我们测WebSocket但这里可以方便地设置服务器名称或IP为localhost和端口号为8080。这样后续的WebSocket Sampler就不用重复填写了。添加第一个采样器打开连接右键线程组 -添加-取样器-WebSocket Open Connection。Path填写/ws。Implementation选RFC6455。Protocol选ws。这个采样器专门用于建立一个持久化的连接不发送应用消息。它相当于底层连接的建立者。添加第二个采样器认证请求右键线程组 -添加-取样器-WebSocket Sampler。Server Name or IP和Port会继承默认值无需填写。Request Data填入{auth: token123}。Response Pattern填入status: ok(注意这里匹配的是响应字符串中的部分不需要完全JSON匹配)。务必勾选Streaming Connection因为我们要复用上一步打开的连接。Close Connection Pattern留空。添加定时器控制心跳间隔在“认证请求”采样器下右键 -添加-定时器-固定定时器。设置线程延迟为10000毫秒10秒。定时器对其作用域内的所有采样器生效。添加第三个采样器心跳请求右键线程组 -添加-取样器-WebSocket Sampler。放在定时器后面。Request Data填入{type: ping}。Response Pattern填入type: pong。务必勾选Streaming Connection。添加第四个采样器发送聊天消息复制第三个采样器心跳请求粘贴到其后。修改Request Data为{type: chat, content: Hello JMeter!}。修改Response Pattern为type: chat(假设服务器会回显类似结构)。Streaming Connection保持勾选。添加第五个采样器关闭连接右键线程组 -添加-取样器-WebSocket Sampler。Request Data可以留空或者发送一个关闭帧{type: close}如果服务端协议支持。关键不要勾选Streaming Connection。这样这个采样器会在发送消息或空消息后主动关闭连接。也可以在Close Connection Pattern中设置一个模式让服务器触发关闭但这里我们用客户端主动关闭。添加监听器查看结果右键线程组 -添加-监听器-查看结果树。再添加一个聚合报告用于后续性能分析。4.3 调试与执行点击工具栏的绿色开始按钮运行。在“查看结果树”中你应该能看到WebSocket Open Connection显示Success。认证请求采样器显示Success并且响应数据中包含{status: ok}。心跳和聊天消息采样器依次成功。最后一个采样器执行后连接关闭。如果任何一步失败检查服务器是否真的在localhost:8080/ws运行请求的JSON格式是否正确是否与服务器期望的完全匹配包括空格、引号Response Pattern设置是否正确是否在服务器返回的消息中能匹配到Streaming Connection的勾选逻辑是否正确尤其是打开连接和关闭连接的采样器。5. 高级场景与性能压测实战单用户调试通过只是第一步。JMeter的强大之处在于模拟高并发。我们来构建一个压测场景。5.1 模拟多用户并发与长连接保持修改线程组将线程数改为50Ramp-Up Period(启动时间) 设为10秒循环次数设为永远。这表示在10秒内启动50个虚拟用户并持续运行。参数化认证信息50个用户不能都用同一个token。我们需要参数化。添加一个CSV 数据文件设置配置元件。指定一个CSV文件里面有一列token有50行不同的token值。在认证请求的Request Data中修改为{auth: ${token}}。控制心跳频率50个用户每秒都发心跳压力太大。我们可以使用随机定时器或高斯随机定时器来让每个用户的心跳间隔在10秒左右随机波动更贴近真实场景。模拟随机发送聊天消息添加一个随机控制器在其下放置多个“发送聊天消息”的采样器内容可参数化并设置权重模拟用户随机发言的行为。长时间运行设置线程组循环为“永远”并搭配调度器设置压测持续时间例如600秒10分钟。观察在长时间保持大量长连接的情况下服务端的内存、CPU和连接数是否稳定。5.2 关键性能监控与断言压测不只是发请求还要判断结果是否正确监控关键指标。添加响应断言在认证请求采样器下右键 -添加-断言-响应断言。测试字段选择响应文本。模式匹配规则选择包含。模式填入status: ok。这样如果服务器返回的不是成功状态该请求会被标记为失败。添加JSON断言如果响应是标准JSON使用JSON Assertion插件需额外安装可以更精确地断言JSON路径下的值例如$.status等于ok。监控连接数在服务端你需要通过监控工具如netstat, Prometheus Grafana来观察ESTABLISHED状态的TCP连接数是否与JMeter的活跃线程数吻合。分析聚合报告重点关注聚合报告监听器中的几个指标Throughput (吞吐量)每秒完成的请求数。对于WebSocket这更多是“消息数/秒”。Average / Median / 95th Percentile (响应时间)从发送消息到收到匹配Response Pattern的消息所花费的时间。这是衡量服务端处理延迟的关键。Error % (错误率)任何失败的请求连接失败、断言失败、超时的百分比。在压测中错误率必须为0或低于可接受阈值如0.1%。5.3 分布式压测与资源监控当单台JMeter机器无法模拟足够压力时需要分布式压测。控制机与执行机在一台机器上运行JMeter GUI作为控制机在多台机器上以jmeter-server(非GUI模式) 启动执行机。同步问题WebSocket连接是有状态的。在分布式压测中一个WebSocket会话的所有请求打开、认证、心跳、关闭必须由同一个JMeter执行机线程完成。不能将同一个用户的请求分发到不同机器。JMeter的线程组本身保证了这一点但需要确保你的测试计划逻辑在一个线程内是完整的。服务器资源监控压测时务必同时监控服务器的系统指标CPU、内存、网络IO和应用指标JVM堆内存、GC次数、线程池活跃数、消息队列长度。使用如jconsole,VisualVM或APM工具如SkyWalking, Arthas。WebSocket服务常见的问题是内存泄漏未正确清理连接上下文和线程阻塞。6. 常见问题排查与实战技巧实录在实际操作中你一定会遇到各种问题。这里记录了我踩过的一些坑和解决方法。6.1 连接失败类问题问题WebSocket Open Connection失败报错java.net.ConnectException: Connection refused。排查首先用telnet或nc命令测试服务器IP 端口是否通。如果不通检查服务器进程是否启动防火墙是否放行。如果通检查JMeter中的协议ws/wss、路径/ws是否正确。问题使用wss协议时连接失败报SSL证书相关错误。排查如果服务器使用自签名证书需要在JMeter的系统属性或测试计划中配置信任所有证书仅限测试环境。可以添加一个HTTP请求默认值或HTTP信息头管理器并设置HTTPS协议为TLS或添加JVM参数-Djavax.net.ssl.trustStore...。更规范的做法是将服务器的自签名证书导入到JMeter运行环境的JVM信任库中。6.2 消息收发类问题问题采样器一直处于“等待响应”状态最终超时。排查这是最常见的问题。首先在“查看结果树”中查看该采样器的请求是否已成功发送请求数据是否正确。然后检查Response Pattern是否设置如果留空JMeter收到任何消息都会成功。如果你期望特定消息就必须设置。模式是否匹配服务器返回的消息可能包含换行符、空格或者JSON格式与你想的不完全一致。建议先将Response Pattern留空运行一次在结果树中精确复制服务器返回的完整消息文本再将其关键部分填入模式中。注意转义特殊字符如双引号。服务器真的推送消息了吗可能你的请求逻辑有误服务器没有触发推送。需要结合服务端日志排查。问题勾选了Streaming Connection但第二个采样器还是新建了连接。排查检查两个采样器的Server Name or IP和Port是否完全一致包括大小写。JMeter是根据这些信息来匹配和复用连接的。另外确保第一个采样器通常是WebSocket Open Connection或第一个未勾选Streaming的Sampler已成功建立连接。6.3 性能与稳定性问题问题压测一段时间后JMeter报java.net.SocketException: Too many open files或Address already in use。排查这是操作系统文件描述符或端口耗尽。对于JMeter机器需要调高单进程可打开的文件数限制Linux下ulimit -n。对于“Address already in use”是因为TCP连接关闭后进入TIME_WAIT状态需要等待2MSL通常1-4分钟才能复用。可以通过优化JMeter的TCP连接复用HTTP请求默认值中设置或调整操作系统net.ipv4.tcp_tw_reuse参数来缓解。更重要的是检查你的测试计划是否正确地关闭了WebSocket连接避免连接泄漏。问题服务器端内存持续增长压测停止后也不下降。排查典型的服务端内存泄漏。使用jmap或VisualVM对服务器JVM做堆转储分析查看WebSocketSession或相关Channel对象是否被意外持有无法被GC回收。检查服务端代码中连接关闭事件的回调函数是否被正确执行并清理了相关资源。6.4 实用技巧使用“Dummy Sampler”模拟等待在等待服务器主动推送的场景可以在两个发送请求之间添加一个“jpgc - Dummy Sampler”需要安装插件设置一个固定的等待时间。这样能更清晰地划分测试逻辑阶段而不是依赖一个超时时间很长的Sampler。将配置提取到“用户自定义变量”将服务器地址、端口、路径、通用请求头等信息放在用户定义的变量配置元件中用${host}、${port}引用。便于在不同环境测试、预生产间切换。使用“While控制器”处理动态交互如果与服务器的交互是动态的例如发送A根据返回的B决定下一步发送C可以使用While控制器结合JSON提取器或正则表达式提取器从响应中获取值并作为循环条件或下一个请求的参数。录制WebSocket流量对于复杂的交互可以先在浏览器中使用开发者工具F12 - Network - WS录制下真实的WebSocket通信过程。记录下连接URL、发送的消息序列和接收的消息。这能极大地帮助你构建正确的JMeter测试脚本。