1. 项目概述为什么需要WebSocket性能测试如果你做过传统的HTTP接口性能测试可能会觉得用JMeter已经轻车熟路了。但当你面对一个实时聊天应用、一个在线协同编辑工具或者一个股票行情推送系统时传统的HTTP请求-响应模型就有点力不从心了。这些场景的核心是WebSocket——一种全双工、长连接的通信协议。它不像HTTP那样“问一句答一句”而是建立连接后服务器可以随时主动给客户端“推送”消息客户端也能随时发消息上去就像打一通永不挂断的电话。这时候问题就来了你熟悉的JMeter默认只支持HTTP/HTTPS、FTP这些协议对WebSocket是“两眼一抹黑”。直接用HTTP采样器去模拟那测出来的结果毫无意义因为你测的根本不是WebSocket连接的生命周期、消息推送的延迟和并发连接稳定性这些核心指标。所以我们必须借助专门的插件来让JMeter“听懂”WebSocket协议。市面上有几个JMeter的WebSocket插件经过我多年的实战筛选WebSocket Samplers by Peter Doornbosch这个插件是社区公认最稳定、功能最全的选择。它提供了多种采样器能完整模拟WebSocket从握手、连接、收发消息到断开的全过程。这篇指南我就带你从零开始手把手搞定这个插件的实战应用不仅告诉你每一步怎么操作更会深入剖析每个参数背后的逻辑以及我在大量压测中踩过的坑和总结出的调优技巧。无论你是要测试一个简单的聊天室还是一个复杂的实时数据看板这套方法都能让你拿到真实、可靠的性能数据。2. 环境准备与插件安装工欲善其事必先利其器。在开始编写任何测试脚本之前确保你的测试环境是干净、正确的这能避免后续一大堆莫名其妙的错误。2.1 JMeter与JDK版本匹配这是最基础也最容易出问题的一步。JMeter是纯Java应用它的运行严重依赖JDKJava Development Kit。JDK版本选择我强烈推荐使用JDK 8或JDK 11的LTS长期支持版本。这两个版本经过最广泛的实践检验与各类库和插件的兼容性最好。高版本JDK如17, 21虽然新但有时会遇到第三方库未及时适配的问题导致插件无法加载或运行异常。JMeter版本选择建议使用JMeter 5.4的版本。这个版本之后的JMeter在性能和稳定性上都有不错的表现。你可以在 Apache JMeter官网 下载最新的二进制包apache-jmeter-5.6.x.zip这样的格式解压即用。验证安装打开命令行分别输入java -version和jmeter -v在JMeter的bin目录下。确保JDK版本符合预期且JMeter能正常启动。如果JMeter启动报错十有八九是JDK环境变量JAVA_HOME没配好或者版本不匹配。注意不要使用JREJava Runtime Environment务必安装完整的JDK。某些插件在编译或运行时会需要JDK中的工具包。2.2 WebSocket插件的安装与验证我们将使用WebSocket Samplers by Peter Doornbosch插件。安装方式有两种推荐第一种。方法一使用JMeter插件管理器推荐这是最省心的方法。如果你安装的JMeter版本里没有Plugins Manager需要先安装它。从 JMeter Plugins Manager官网 下载plugins-manager.jar文件。将这个jar包放入JMeter安装目录的lib/ext文件夹下。重启JMeter你会在“选项”(Options)菜单中看到“Plugins Manager”。打开Plugins Manager切换到“Available Plugins”标签页。在搜索框输入“WebSocket”找到“WebSocket Samplers by Peter Doornbosch”勾选它然后点击右下角的“Apply Changes and Restart JMeter”。管理器会自动下载依赖并重启JMeter。方法二手动下载安装前往该插件的 GitHub Releases页面 注意Peter Doornbosch的原始项目已由Maciej Zaleski维护。下载最新的jmeter-websocket-samplers-xxx.jar文件例如jmeter-websocket-samplers-1.2.8.jar。将这个jar包放入JMeter安装目录的lib/ext文件夹下。重启JMeter。验证安装是否成功 重启JMeter后在测试计划上右键选择“添加” - “取样器”(Sampler)。如果你在列表中看到了类似WebSocket Open Connection,WebSocket request-response Sampler等选项恭喜你插件安装成功了。2.3 测试目标环境搭建为了实战演示我们需要一个WebSocket服务端。这里我推荐两个极简的快速搭建方案你可以任选其一方案A使用在线测试服务最快像wss://echo.websocket.org这样的公共服务它会把客户端发送的消息原样返回。非常适合用来验证你的JMeter脚本是否基本工作正常。但注意它不适合做高并发压测且有使用限制。方案B本地运行一个简单的WebSocket服务器推荐这样你拥有完全控制权。这里用Node.js写一个不到20行的例子确保你安装了Node.js。创建一个文件夹在里面新建一个文件server.js写入以下代码const WebSocket require(ws); const server new WebSocket.Server({ port: 8080 }); console.log(WebSocket server started on ws://localhost:8080); server.on(connection, (socket) { console.log(New client connected); socket.on(message, (message) { console.log(Received: ${message}); // 原样返回消息 socket.send(Echo: ${message}); }); socket.on(close, () { console.log(Client disconnected); }); });在终端进入该目录运行npm install ws安装依赖然后运行node server.js。你的本地WebSocket服务器就在ws://localhost:8080运行起来了。有了这个“回声”服务器我们就可以放心地进行后续的所有测试了。3. 核心采样器详解与脚本编写插件提供了多个采样器理解它们各自的分工是编写正确脚本的关键。我会用一个模拟用户加入聊天室、发送消息、接收广播、最后离开的完整场景来串联讲解。3.1 WebSocket Open Connection建立连接这是所有WebSocket测试的第一步相当于“拨号”。它的作用是与服务器完成WebSocket握手建立一个持久连接。放在哪里通常放在“仅一次控制器”Once Only Controller或“ setUp线程组”中。因为对于一个虚拟用户线程来说连接只需要建立一次然后在后续步骤中复用这个连接。如果放在普通采样器中每次循环都会创建新连接这不符合大多数业务场景也会给服务器带来不必要的开销。关键参数解析Server Name or IP服务器地址如localhost或echo.websocket.org。Port Number端口如8080或443WSS默认。PathWebSocket连接的路径例如/chat。如果服务器根路径就是WebSocket端点这里可以留空。Implementation选择RFC6455。这是WebSocket的现行标准协议。Connection Idle Timeout连接空闲超时时间毫秒。我通常设置为3000005分钟或更长防止在长间隔发送消息时连接被意外关闭。这是一个重要的调优点设得太短可能在测试中途断连。Connection Label给这个连接起个名字比如User_${__threadNum}_Connection。这在后续采样器中用于指定使用哪个连接尤其在模拟多用户各自保持独立连接时至关重要。实操心得务必勾选“Add Tracking ID to request header”。这个跟踪ID会在响应头中返回在调试时可以帮助你确认这个响应对应的是哪个请求尤其是在高并发下消息乱序时非常有用。3.2 WebSocket request-response Sampler请求与响应这是最常用、功能最强大的采样器。它模拟一次“发送-接收”的完整交互。你可以用它来发送登录报文、查询指令或者像聊天一样发送一条消息并等待回复。关键参数解析WebSocket Connection选择之前WebSocket Open Connection采样器中定义的Connection Label。这指明了使用哪个连接来发送消息。Request Data要发送给服务器的数据。可以是纯文本如JSON字符串、二进制数据需要特殊编码。这里有个大坑如果你发送的是JSON务必确保是合法的JSON格式并且字符串中不能有未转义的特殊字符如换行、引号。我习惯先用一个“用户定义的变量”或“JSR223预处理器”来构造JSON再通过${变量名}引用到这里。Response Pattern等待响应的模式这是核心。Wait for response一直等待直到收到任何响应。容易超时。Wait for matching response等待一个特定内容的响应。比如你发送了“登录”可以在这里填写status:success采样器会持续监听直到收到的消息中包含这个字符串为止。这是最精准的模式能模拟真实的业务等待。Wait for timeout不管收没收到响应等待固定时间后就结束。Close Connection通常不勾选。勾选后本次请求-响应结束后会关闭连接这意味着下一个采样器无法再使用这个连接了。场景示例用户发送聊天消息假设我们的聊天消息格式是{type:chat, user:${username}, msg:Hello, world!}。在Request Data中填入上述JSON注意username可以用JMeter变量。Response Pattern设置为Wait for matching response并在下方填写type:chat_ack假设服务器成功处理后会返回一个确认报文。设置一个合理的Response Timeout如5000毫秒。如果5秒内没收到确认这个采样器就会标记为失败。3.3 WebSocket Ping/Pong Sampler心跳保活WebSocket协议内置了Ping/Pong帧用于心跳检测保持连接活跃并探测连接是否存活。这个采样器就是用来发送Ping帧并期待Pong帧回复的。何时使用在长连接测试中如果你需要模拟真实客户端的心跳机制就应该定期例如每30秒插入这个采样器。将它放在一个“固定定时器”Constant Timer后面并置于“循环控制器”Loop Controller中。参数非常简单主要就是指定WebSocket Connection。超时时间可以设得短一些比如2000毫秒因为Pong应该立刻返回。重要提示不是所有服务器都严格实现Ping/Pong。有些服务器可能会忽略Ping帧或者以其他方式实现保活。在测试前最好先用工具如浏览器开发者工具中的WebSocket面板验证一下你的目标服务器是否响应Ping。如果不响应这个采样器总会超时失败。3.4 WebSocket Close Connection优雅断开测试结束时或者模拟用户退出时应该主动关闭连接而不是直接结束线程。这是一种“礼貌”的行为也更能反映真实场景。参数指定要关闭的WebSocket Connection。StatusCode和Reason可以按照协议规范填入关闭代码和原因例如状态码1000正常关闭原因Goodbye。服务器端可能会记录这些信息。完整脚本结构示例一个虚拟用户的动线测试计划 ├─ 用户定义的变量设置服务器、端口、路径等 ├─ 线程组循环次数永久时长300秒 │ ├─ 仅一次控制器 │ │ └─ WebSocket Open Connection (建立连接标签conn_${__threadNum}) │ ├─ 事务控制器模拟登录 │ │ ├─ WebSocket request-response Sampler (发送登录报文) │ │ └─ JSON提取器从登录响应中提取sessionId │ ├─ While控制器条件${__jm__Thread Group__idx} 300 // 模拟持续活动 │ │ ├─ 高斯随机定时器模拟用户思考时间 │ │ ├─ WebSocket request-response Sampler (发送一条聊天消息) │ │ ├─ 固定定时器延迟30秒 │ │ └─ WebSocket Ping/Pong Sampler (发送心跳) │ └─ WebSocket Close Connection (关闭连接) └─ 监听器查看结果树、聚合报告等4. 高级配置与性能调优脚本能跑通只是第一步要模拟真实压力并得到可信数据还需要精细的配置和调优。4.1 模拟真实用户行为定时器与思考时间真实的用户不会像机器一样毫秒不差地连续发送请求。他们之间有“思考时间”。高斯随机定时器Gaussian Random Timer这是我最常用的定时器。它模拟大部分请求间隔在一个平均值附近但有一定随机波动非常符合人类操作的不确定性。你需要设置“偏差”Deviation和“常数延迟”Constant Delay。例如设置常数延迟3000毫秒偏差1000毫秒那么大部分请求间隔会在2秒到4秒之间。同步定时器Synchronizing Timer如果你想模拟“秒杀”场景——大量用户在某一精确时刻同时发起请求如发送消息就用这个定时器。它会让线程在到达这个定时器时阻塞直到达到你设置的“模拟用户组的数量”后再一起释放。慎用因为它会制造非常极端的瞬间压力。实操心得永远不要在“线程组”的“Ramp-up period”里寄托模拟思考时间的希望。Ramp-up是用于控制线程启动节奏的。思考时间必须用定时器在采样器之间显式添加。4.2 参数化与数据驱动不能让所有虚拟用户都发送一模一样的消息。你需要参数化。CSV数据文件设置CSV Data Set Config这是数据驱动的核心。准备一个CSV文件里面包含username, message等列。在配置元件中添加CSV Data Set Config指定文件路径、变量名。然后在Request Data中使用${username}和${message}。用户定义的变量定义一些全局的静态参数如服务器地址、端口。函数助手使用__RandomString,__Random,__time等函数动态生成数据。例如消息内容可以是__RandomString(10, abcdefghijklmnopqrstuvwxyz)来生成随机字符串。JSR223预处理器对于复杂的动态报文比如需要根据上一个响应结果来构造下一个请求这是终极武器。你可以用Groovy或Java代码灵活地生成任何格式的请求数据并赋值给JMeter变量。4.3 连接管理与资源清理每个线程独立连接这是最常见的模式。在WebSocket Open Connection的Connection Label中使用${__threadNum}来确保每个虚拟用户线程建立并维护自己独立的连接。这模拟了多个真实用户同时在线。连接池高级在某些特殊场景下你可能想模拟少量客户端连接但通过每个连接发送极高频率的请求。这需要更复杂的脚本逻辑可能需要在“ setUp线程组”中建立连接并存储在全局属性中供其他线程组使用。这通常不是WebSocket测试的典型模式且容易引发线程安全问题新手不建议尝试。超时设置连接超时在WebSocket Open Connection中设置。不要设太短网络稍有波动就可能失败。响应超时在每个WebSocket request-response Sampler中设置。这个值需要根据业务逻辑的预期来定。如果是“发送消息并等待对方回复”这种交互可能需要几秒如果是“发送指令等待执行结果”可能需要更久。设置不当是导致测试结果失真的主要原因之一。设太短很多正常请求会被误判为失败设太长会掩盖服务器处理慢的问题。5. 监听、断言与结果分析测试执行了你怎么知道它成功了还是失败了又怎么衡量性能好坏5.1 断言定义什么是“成功”JMeter默认认为收到响应就是成功但这对于WebSocket测试远远不够。我们必须用断言来验证响应内容是否正确。响应断言Response Assertion最常用。可以针对“响应数据”即收到的WebSocket消息正文进行断言。要测试的字段选择Response Message。模式匹配规则选择Contains或Matches正则表达式。要测试的模式填写你期望服务器返回的内容片段。例如登录成功后返回的JSON中包含code:0。JSON断言如果响应是JSON格式用这个更精准。可以直接通过JSONPath表达式来提取和断言特定字段的值比如$.status等于success。持续时间断言用来判断响应是否太快可能走了缓存或太慢。例如设置“持续时间”大于100毫秒且小于2000毫秒超出这个范围的请求标记为失败。配置位置断言通常作为采样器的“子元件”添加。一个采样器可以添加多个断言所有断言都通过该采样器才算成功。5.2 关键监听器洞察性能数据不要只会用“查看结果树”在压测时它会产生海量数据严重消耗性能只应在调试时使用。性能测试主要看以下几个监听器聚合报告Aggregate Report这是核心中的核心。它提供了所有取样器的统计摘要。平均值Average平均响应时间。关注这个值是否在业务可接受范围内。中位数Median50%的请求响应时间低于这个值。比平均值更能抵抗极端值的影响。90%/95%/99%百分位90% Line, etc.例如90% Line800ms表示90%的请求响应时间在800ms以内。这个指标比平均值更重要它告诉你大多数用户的体验。如果99% Line很高说明有少量请求非常慢需要排查。吞吐量Throughput每秒完成的请求数。这是系统处理能力的直接体现。接收/发送KB/sec网络吞吐量。错误率Error %失败请求的百分比。理想情况下应为0%但实际中需结合业务定义可接受的错误率如0.1%。响应时间图Response Time Graph直观展示响应时间随时间的变化趋势。如果曲线随着测试进行持续攀升说明系统可能存在内存泄漏或资源耗尽如果曲线剧烈抖动说明系统不稳定。活动线程数图Active Threads Over Time验证你的压力模型是否符合预期如阶梯加压、波浪形加压。后端监听器Backend Listener如果你需要将测试结果实时发送到时序数据库如InfluxDB然后用Grafana制作炫酷的监控大屏就需要配置这个。这对于长期监控和自动化测试集成非常有用。5.3 结果分析与性能瓶颈定位拿到数据后如何分析首先看错误率如果错误率很高比如1%性能测试基本失去意义。先解决错误问题。查看“查看结果树”或“用表格察看结果”监听器分析失败请求的响应数据和响应码定位是脚本问题如断言太严、参数化错误、网络问题还是服务端问题。其次看响应时间百分位重点关注90% Line和99% Line。如果它们远高于平均值说明有“长尾请求”少数用户体验很差。需要结合服务器监控CPU、内存、磁盘I/O、网络IO、数据库慢查询日志、应用日志来定位这些慢请求的原因。然后看吞吐量随着并发用户数线程数增加吞吐量是否线性增长达到某个点后吞吐量是否不再增长甚至下降那个点可能就是系统的性能拐点。同时观察此时服务器的CPU使用率是否已达到瓶颈如接近100%。关联资源监控性能测试一定要同时监控服务器资源使用top,vmstat,iostatLinux或资源监视器Windows等工具。一个典型的瓶颈判断流程如果吞吐量上不去且CPU使用率很高 - 可能是应用代码或数据库查询存在性能瓶颈需要优化。如果吞吐量上不去但CPU使用率不高 - 可能是磁盘I/O瓶颈、网络带宽瓶颈、或者应用在等待外部服务如数据库连接池耗尽、第三方API响应慢。如果错误率伴随“连接拒绝”增加 - 可能是服务器连接数文件描述符或线程池已满。6. 实战踩坑记录与排查指南这里分享几个我印象深刻的“坑”希望能帮你节省大量排查时间。坑1WebSocket request-response Sampler一直等待直到超时现象采样器一直转圈最后超时失败。排查检查Response Pattern是否设置为Wait for matching response并且你填写的“模式”字符串完全正确包括大小写、空格和标点。服务器返回的是{status:ok}你写成status:OK就会永远等不到。在“查看结果树”中查看这个采样器是否真的收到了服务器的消息。可能消息早就收到了只是因为模式不匹配而被忽略。可以暂时将模式改为Wait for response来验证。检查服务器端逻辑确认它确实会对你发送的请求进行回复。坑2高并发下连接随机失败错误信息含“连接重置”现象在几十或几百个线程并发时部分WebSocket Open Connection失败。排查首先检查服务器端WebSocket服务器本身有并发连接数限制。检查服务器配置如Nginx的worker_connections Node.js ws库的服务器实例配置或应用服务器的连接池设置。检查客户端JMeter所在机器操作系统对单个进程可打开的文件描述符数量有限制。在Linux下用ulimit -n查看。对于大规模压测可能需要用ulimit -n 65535命令临时提高限制。检查网络如果是压测公网服务可能是本地网络出口带宽或端口数受限。坑3测试运行一段时间后吞吐量急剧下降错误率飙升现象测试前期一切正常几分钟或十几分钟后系统开始变慢大量请求失败。排查内存泄漏这是最常见的原因。观察JMeter GUI如果是在GUI模式下运行和服务器端应用的内存使用情况是否持续增长而不释放。对于JMeter尽量使用非GUI模式jmeter -n -t test.jmx -l result.jtl进行压测并给JVM分配合适的内存修改jmeter.bat或jmeter.sh中的HEAP参数。服务器资源耗尽检查服务器CPU、内存、磁盘空间。特别是磁盘如果日志输出过于频繁可能会写满磁盘。连接未关闭确认你的测试脚本在最后正确地关闭了WebSocket连接。如果每个线程只创建连接而不关闭随着线程迭代连接数会无限增长最终耗尽资源。确保WebSocket Close Connection采样器被执行到。坑4如何测试服务器主动推送消息的场景场景比如股票行情服务器会不定时向所有已连接客户端推送数据客户端主要是在接收。JMeter模拟方法这需要一点技巧。你不能用一个简单的请求-响应采样器来等因为不知道消息什么时候来。方案A使用单个长等待采样器在建立连接后添加一个WebSocket request-response SamplerRequest Data可以发送一个订阅指令如{action:subscribe}然后将Response Timeout设置为一个很长的值比如测试持续时间60秒。在这个超时时间内这个采样器会持续监听连接任何从服务器推送过来的消息都会被这个采样器捕获并记录为“响应”。你可以在后面添加“断言”来验证推送消息的格式和内容。缺点是一次循环只能接收一次推送流。方案B使用While控制器和短超时更灵活。将WebSocket request-response Sampler放在一个While控制器内。采样器设置一个较短的超时如2秒并勾选“Read Response Message without sending request?”这是一个隐藏但关键的功能在这个插件的某些版本或变体中可能存在或者需要通过其他采样器如WebSocket Single Read Sampler实现。这样采样器会不断地尝试“读取”消息如果2秒内读到就成功并记录如果没读到就超时可以视为正常不标记为失败然后循环继续。While控制器的条件可以设置为测试时间。这种方案能更好地模拟客户端持续在线的状态并统计接收到的消息数量。最后性能测试是一门实践的艺术。再完善的脚本第一次运行也可能出问题。我的习惯是从小规模开始。先用1个线程循环几次用“查看结果树”确保整个脚本逻辑连接-登录-发消息-收消息-断开是通的。然后逐步增加到5个、10个线程观察错误率和基础响应时间。最后再上到几百上千的并发同时严密监控服务器资源。这个过程本身也是对你被测系统认知加深的过程。