1. 项目概述为什么需要WebSocket多会话压测如果你做过传统的HTTP接口压测可能会觉得用JMeter已经轻车熟路了。但当你面对一个需要实时双向通信的应用比如在线聊天室、股票行情推送、协同编辑文档或者实时游戏时传统的HTTP请求-响应模型就完全不够用了。这时候WebSocket协议登场了。它建立一次连接就能在客户端和服务器之间保持一个全双工的通信通道数据可以随时从任何一方推送到另一方。问题就出在这里。你用JMeter压测一个登录接口模拟100个用户就是发100个HTTP请求收到100个响应干净利落。但压测WebSocket呢你模拟的100个用户每个都需要先完成一次“握手”建立连接然后这个连接会一直保持着。服务器需要同时维护这100个长连接处理它们随时可能发来的消息还要主动向它们推送数据。这对服务器的连接管理、内存消耗、消息分发机制都是巨大的考验。一个HTTP接口可能扛得住每秒1000次请求但同一个服务开放WebSocket可能100个长连接就让它内存告急、响应迟缓了。所以“多会话”是这个实战的核心。它不再是简单的“多发请求”而是模拟真实场景下成百上千个独立的客户端与服务器建立并保持长连接并在连接上进行持续的、双向的通信。这能暴露出单用户测试或简单接口测试无法发现的问题连接泄漏、内存增长、消息广播效率、连接数上限等。我最近就遇到一个项目单功能测试一切正常一上多会话压测连接数超过500服务器就出现明显的响应延迟和部分连接异常断开这就是压力测试的价值所在。接下来我会带你从零开始拆解如何用JMeter完成一次地道的WebSocket多会话压力测试。我们会用到必要的插件设计合理的测试场景并解读关键结果。你会发现虽然步骤稍多但思路清晰后一切都有迹可循。2. 核心工具与插件选型工欲善其事必先利其器。JMeter本身并不原生支持WebSocket协议所以我们需要借助第三方插件。这里有几个选择但经过多次实战我主要推荐和使用下面这一套组合。2.1 JMeter与WebSocket插件首先确保你安装了合适版本的JMeter。我目前使用的是 Apache JMeter 5.6.3它需要Java 8或更高版本的环境。安装过程很简单官网下载解压即可这里不赘述。核心在于WebSocket插件。社区里主要有两个流行的选择WebSocket Samplers by Peter Doornbosch这是较早且广泛使用的插件功能比较基础。WebSocket Plugin by Maciej Zaleski我强烈推荐这个。它的功能更强大、更新更活跃对WebSocket协议的支持更完整尤其是对多会话、异步消息处理的支持更好。如何安装以推荐的 Maciej Zaleski 插件为例访问插件的GitHub发布页面下载最新的jmeter-websocket-*.jar文件。将这个JAR文件复制到你的JMeter安装目录下的lib/ext文件夹中。重启JMeter。重启后你在线程组上右键添加Sampler时应该能看到WebSocket Open Connection,WebSocket request-response Sampler,WebSocket Ping/Pong Sampler,WebSocket Close Connection等新的采样器这就说明安装成功了。注意插件的版本需要与你的JMeter版本大致兼容。如果遇到启动报错或采样器不可用通常是版本不匹配尝试更换插件版本或JMeter版本。2.2 辅助监听器与配置元件除了核心的WebSocket采样器一个完整的压测脚本还需要其他元件配合线程组Thread Group这是压测的发动机用来定义虚拟用户数线程数、启动时间、循环次数等。对于多会话压测线程数就对应着要模拟的独立WebSocket连接数。HTTP请求采样器HTTP Request Sampler等等不是WebSocket吗没错WebSocket连接始于一个HTTP握手。通常我们需要先用一个HTTP请求模拟发送WebSocket升级请求Upgrade request。虽然插件可能封装了这部分但理解这个过程对排查问题很有帮助。用户定义的变量User Defined Variables用来集中管理主机名、端口、路径等配置方便脚本维护。监听器Listeners用来收集和查看结果。必备的有查看结果树View Results Tree调试脚本时极其有用可以查看每个请求和响应的详细内容。但正式压测时务必禁用或删除它因为它会消耗大量内存严重影响压测性能。聚合报告Aggregate Report正式压测的核心监听器提供平均响应时间、吞吐量、错误率等关键指标。图形结果Graph Results或响应时间图Response Time Graph可视化观察响应时间趋势。后端监听器Backend Listener如果你希望将结果实时发送到时序数据库如InfluxDB并用Grafana展示这是专业压测的标配。3. 测试场景设计与脚本架构直接上手写脚本很容易迷失。我们先花点时间设计一下要模拟什么。一个典型的WebSocket多会话压测场景通常包括以下阶段连接建立阶段模拟N个用户分别与服务器建立WebSocket连接。这对应着服务器的“握手”和连接创建能力。稳定通信阶段连接建立后模拟这些用户进行一系列操作。例如心跳/保活定期发送Ping或特定心跳消息防止连接被中间设备断开。发送消息用户主动向服务器发送数据如聊天消息、操作指令。接收推送服务器主动向部分或全部连接推送数据如广播消息、状态更新。我们需要验证客户端是否能正确、及时地收到这些消息。连接关闭阶段模拟用户正常或异常断开连接。测试服务器是否能正确释放资源。基于这个流程我们的JMeter脚本架构可以这样规划线程组 (Thread Group: 模拟100个用户) ├── 用户定义的变量 (配置服务器地址、端口等) ├── 循环控制器 (控制整个会话的生命周期例如循环5次) │ ├── WebSocket Open Connection (建立连接) │ ├── 定时器 (等待模拟用户思考时间) │ ├── WebSocket Request-Response Sampler (发送消息并等待响应) │ ├── While控制器 (用于持续监听服务器推送) │ │ └── WebSocket Request-Response Sampler (配置为只读接收消息) │ ├── 定时器 (再次等待) │ └── WebSocket Close Connection (关闭连接) ├── 聚合报告 (收集性能数据) └── 响应时间图 (观察趋势)关键设计点解析线程数与会话线程组中的“线程数”直接等于你要模拟的独立WebSocket会话数。100个线程就是100个同时保持的长连接。连接复用WebSocket Open Connection采样器会建立一个连接并为这个连接创建一个“连接名称”Connection Name。后续的所有发送、接收、关闭操作都需要通过这个“连接名称”来指定操作哪个连接。这是实现多会话独立性的关键。接收服务器推送这是难点。WebSocket通信是异步的服务器可能随时发消息。JMeter脚本是顺序执行的如何“等待”并“捕获”推送的消息常用的方法是使用While控制器配合一个“只读”的 WebSocket Request-Response Sampler。在While控制器中设置一个条件比如超时时间或检查某个变量然后循环执行那个“只读”采样器。这个采样器不发送数据只是尝试从指定连接读取消息。一旦读到消息就跳出循环或进行下一步处理。思考时间Timer在操作之间加入高斯随机定时器Gaussian Random Timer等可以更真实地模拟用户操作的不确定性避免请求洪峰。4. 详细脚本配置与实操步骤现在我们进入实操环节一步步配置脚本。假设我们要测试一个简单的WebSocket回声服务ws://localhost:8080/echo它会把客户端发送的消息原样返回。4.1 第一步创建线程组与基础配置打开JMeter右键测试计划 - 添加 - 线程用户 -线程组。配置线程组线程数模拟用户数100Ramp-Up时间秒10 表示在10秒内启动全部100个线程而不是瞬间启动给服务器一个缓冲循环次数5 每个线程执行整个脚本5次。如果想长时间压测可以勾选“永远”4.2 第二步配置公共变量右键线程组 - 添加 - 配置元件 -用户定义的变量。 添加以下变量方便后续引用server:localhostport:8080path:/echoconnection_prefix:WS_Conn_连接名称的前缀后面会加上线程号以保证唯一性4.3 第三步建立WebSocket连接右键线程组 - 添加 - 取样器 -WebSocket Open Connection。Server Name or IP:${server}Port Number:${port}Path:${path}Connection Name:${connection_prefix}${__threadNum}这是关键__threadNum是JMeter函数获取当前线程号。这样线程1的连接叫WS_Conn_1线程2的叫WS_Conn_2彼此独立。Protocol:ws如果是加密的WebSocket over TLS则填wssRead Response Pattern: 可以留空或填写一个预期握手成功的响应片段用于断言。实操心得在“Implementation”下拉菜单中插件通常提供“RFC6455”选项这是WebSocket的标准协议版本大多数情况下选它就行。如果服务端比较特殊可能需要尝试其他实现。4.4 第四步发送消息与接收响应右键线程组 - 添加 - 取样器 -WebSocket request-response Sampler。Connection Name:${connection_prefix}${__threadNum}指定操作哪个连接Request Data: 这里填写要发送的消息。例如Hello from thread ${__threadNum}。你可以使用JMeter函数生成更复杂的动态数据。Response Timeout (ms): 设置等待服务器响应的超时时间比如5000毫秒。Close Connection?: 不要勾选。我们发送消息后不希望关闭连接。Read Response Pattern: 可以填写一个预期响应中包含的文本用于断言。对于回声服务可以填Hello from thread ${__threadNum}。这个采样器完成了“发送请求并等待响应”的同步操作。但WebSocket服务器也可能主动异步推送消息不一定是针对我们请求的回复。4.5 第五步处理服务器主动推送关键难点这是模拟真实场景的核心。我们需要让脚本能够“监听”来自服务器的消息。添加While控制器右键线程组 - 添加 - 逻辑控制器 -While控制器。设置循环条件在While控制器的“Condition”中可以设置一个复杂的条件。一个简单实用的方法是使用变量和超时控制。例如先在While控制器前添加一个BeanShell取样器或JSR223取样器推荐性能更好用脚本设置一个开始时间变量vars.put(listen_start, ${__time()});在While控制器的Condition中填写${__javaScript(${__time()} - ${listen_start} 10000,)}。这个条件表示如果当前时间减去开始监听的时间小于10000毫秒10秒就继续循环。这样就实现了一个10秒的监听窗口。在While控制器内添加“只读”采样器右键While控制器 - 添加 - 取样器 -WebSocket request-response Sampler。Connection Name:${connection_prefix}${__threadNum}Request Data:留空。不发送任何数据。Response Timeout (ms): 设置一个较短的值比如1000毫秒。这个采样器会等待1秒看是否有数据到达。如果没有它就超时并继续下一次循环。Close Connection?: 不要勾选。在这个采样器后面可以添加响应断言检查收到的消息是否符合预期比如是广播消息的格式。如果收到消息你可以用另一个BeanShell/JSR223取样器来处理消息内容或者设置一个标志变量让While循环提前退出vars.put(message_received, true); 然后将While条件改为${__javaScript(${__time()} - ${listen_start} 10000 !\true\.equals(vars.get(\message_received\)),)}。注意事项这种“轮询”读取的方式会消耗一定的CPU资源。如果模拟的连接数非常大比如上万每个连接都用一个短超时的循环去读会给JMeter自身带来很大压力。对于纯粹测试服务器推送能力的场景有时会设计成客户端发送一个“订阅”请求后就进入一个长超时的读取等待。4.6 第六步关闭WebSocket连接在会话的最后右键线程组 - 添加 - 取样器 -WebSocket Close Connection。Connection Name:${connection_prefix}${__threadNum}Close Timeout (ms): 设置关闭操作的超时时间例如2000毫秒。4.7 第七步添加监听器与运行调试添加聚合报告和响应时间图。在正式压测前务必禁用或删除“查看结果树”或者将其放在一个仅用于调试的线程组中。先将线程数设为1循环1次运行脚本。通过查看结果树检查连接是否成功建立、消息是否正常收发、连接是否正常关闭。这是调试阶段。调试无误后将线程数、Ramp-Up时间、循环次数调整到你的目标压力水平进行正式压测。5. 关键参数配置与性能调优脚本能跑通只是第一步要获得有意义的压测结果必须合理配置JMeter自身和测试参数。5.1 JMeter自身调优JVM堆内存WebSocket多会话测试会占用大量内存每个连接、每个线程都有开销。编辑JMeter启动脚本jmeter.bat或jmeter调整HEAP参数。例如set HEAP-Xms4g -Xmx8g -XX:MaxMetaspaceSize1g。具体大小视你的测试规模和机器内存而定。禁用图形界面GUI进行压测GUI模式本身消耗资源。正式压测时应使用命令行CLI模式运行JMeter并将结果保存为JTL文件事后用GUI打开分析。jmeter -n -t your_test_plan.jmx -l result.jtl -e -o ./report(-n非GUI模式-t指定脚本-l指定结果文件-e -o生成HTML报告)减少不必要的监听器如前述只保留聚合报告等轻量级监听器。5.2 测试策略参数Ramp-Up时间不要设置为0。瞬间发起大量连接建立请求对服务器和网络都是冲击可能无法反映真实场景。根据目标合理设置一个爬坡时间比如30秒内启动1000个用户。循环次数与持续时间对于长连接压测更关注稳定状态下的表现。可以设置线程组“永远”循环然后使用调度器Scheduler来指定压测的持续时间例如持续运行10分钟。这样能观察服务器在长时间压力下的内存、连接数是否稳定。超时时间设置WebSocket Open Connection超时设置合理的连接建立超时如5000ms。Request-Response超时根据业务逻辑的预期响应时间设置。太短会导致大量超时错误太长会拖慢测试节奏。Close Connection超时一般2000-5000ms足够。思考时间Timer在高并发下思考时间会显著降低实际对服务器施加的压力吞吐量。在测试系统极限时可以去掉思考时间。在模拟真实用户行为场景时则需要加上。6. 结果分析与性能瓶颈定位压测跑完了看着聚合报告里的一堆数字该怎么看哪些是关键指标6.1 核心性能指标解读样本数Samples总共发出的请求数包括Open Request Close等。平均响应时间Average所有请求的平均耗时。重点关注WebSocket Open Connection和WebSocket request-response的平均时间。连接建立时间反映了服务器的握手处理能力请求响应时间反映了业务逻辑处理能力。吞吐量Throughput每秒完成的请求数Requests per Second。对于WebSocket这个指标需要结合场景看。如果是测试消息收发它可以反映服务器处理消息的速度。错误率Error %这是最重要的指标之一。任何非零的错误率都需要深究。是连接拒绝超时还是消息格式错误接收/发送字节数可以粗略评估网络流量。活动线程数Active Threads Over Time通过“活动线程数”监听器可以确认压力是否按照Ramp-Up设置平稳施加。6.2 如何定位瓶颈高错误率首先看错误类型。如果是“Connection refused”可能是服务器端口未监听或连接数已达上限。如果是“Timeout”则需要区分是连接建立超时还是请求响应超时。连接建立超时检查服务器握手逻辑、网络防火墙请求响应超时检查服务器业务逻辑性能。响应时间随并发增长而急剧上升这是典型的性能瓶颈迹象。可能的原因服务器CPU/内存瓶颈通过服务器监控如top,htop,vmstat观察资源使用率。数据库或下游服务瓶颈如果WebSocket服务需要频繁访问数据库或调用其他服务这里可能成为瓶颈。需要结合应用日志和下游监控判断。线程池耗尽服务器处理连接的线程池大小可能不够。检查服务器配置。JMeter自身成为瓶颈观察运行JMeter的机器CPU和内存使用率。如果JMeter进程CPU占用率很高可能意味着它已经无法产生更大的压力了需要考虑使用分布式压测。吞吐量上不去即使增加并发用户数吞吐量也不再增长甚至下降。这通常意味着系统已经达到性能拐点。可能的原因同上需要综合资源监控和应用日志分析。内存泄漏在长时间压测中观察服务器内存使用率是否持续线性增长即使压力稳定。这可能是连接未正确关闭、对象未释放导致的内存泄漏。需要结合GC日志和内存分析工具如jstat,jmap,VisualVM进行诊断。实操心得压测时一定要同时监控服务器端的各项指标CPU、内存、磁盘IO、网络IO、连接数、线程状态。将JMeter的结果与服务器监控图表的时间轴对齐能非常直观地定位问题。例如发现响应时间尖峰的时刻恰好对应服务器CPU使用率的100%时刻那么瓶颈很可能就在CPU上。7. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种问题。这里记录几个我踩过的坑和解决方法。问题1WebSocket连接建立失败返回“101”状态码以外的错误。排查首先在“查看结果树”中仔细查看WebSocket Open Connection采样器的响应头和响应体。常见的400错误可能是Path不对403错误可能是缺少必要的Header如Origin、Cookies或认证Token。WebSocket握手本质上是一个带有特殊Header的HTTP GET请求。解决在WebSocket Open Connection采样器中检查“Request Headers”部分。你可能需要手动添加Header例如Origin: http://yourdomain.com或Authorization: Bearer xxx。有些服务端对Header有严格要求。问题2连接成功建立但发送消息后收不到响应或者收到乱码。排查确认WebSocket request-response Sampler中的“Connection Name”是否填写正确必须和Open阶段的一致。检查发送的“Request Data”格式服务器期望的是文本Text还是二进制Binary插件通常默认是文本。如果服务器发送的是二进制帧JMeter插件可能无法正确解码。解决在采样器的“Implementation”或高级选项里查看是否有数据帧类型Data Frame Type的选项尝试切换。对于复杂的二进制协议JMeter可能不是最佳工具可以考虑使用其他专门支持二进制WebSocket的压测工具或者自己编写Java代码实现Sampler。问题3模拟大量用户如5000时JMeter本身报“java.net.SocketException: Too many open files”或内存溢出OOM。排查这是Linux/Unix系统对单个进程打开文件描述符数量的限制。每个TCP连接包括WebSocket都是一个文件描述符。解决增加系统限制临时提高限制ulimit -n 65535。永久修改需要编辑/etc/security/limits.conf。使用分布式压测这是解决单机JMeter瓶颈的根本方法。在一台控制机Controller上配置多台压力机Agent。压力机分担连接数。注意WebSocket连接是有状态的需要确保同一个虚拟用户的整个会话Open Request Close在同一个压力机上执行。JMeter的分布式测试需要做一些额外配置来保证这一点。优化JMeter脚本减少不必要的采样器和监听器使用更高效的JSR223脚本语言如Groovy替代BeanShell。问题4如何验证服务器推送的消息被所有客户端正确接收解决这是一个断言问题。在用于接收推送的“只读”WebSocket采样器后添加响应断言。断言内容可以根据业务来定。例如如果服务器广播一条消息格式为{type:broadcast, content:...}你可以在响应断言中检查响应数据是否包含type:broadcast。更高级的验证可以使用JSR223断言或BeanShell断言。在断言脚本中你可以解析收到的JSON消息检查其内容甚至维护一个计数器。例如每个线程在收到特定的全局广播消息后将一个全局共享的计数器通过JMeter属性props加1。最后在测试计划的末尾通过一个特殊的线程组来检查这个计数器的值是否等于总线程数从而验证所有客户端是否都收到了广播。问题5压测结果中平均响应时间看起来正常但90%或95%百分位响应时间90th/95th Percentile非常高。解读这是一个非常重要的信号。平均时间可能被大多数快的请求拉低了但有一小部分请求比如5%或10%非常慢。这通常意味着系统存在不均衡或偶发性问题比如垃圾回收GC停顿、某些请求触发了慢查询、锁竞争等。行动查看响应时间分布图Response Time Percentiles。同时分析这段时间的服务器GC日志和慢查询日志。可能需要优化代码、调整JVM参数或数据库索引。最后记住压测的黄金法则循序渐进监控先行。不要一开始就上最大并发。从低并发开始逐步增加观察各项指标的变化曲线找到系统的性能拐点和瓶颈点。每一次压测目标不仅仅是得到一个“能扛多少并发”的数字更是为了发现系统的弱点并推动其优化。这个过程本身就是对系统架构和理解的一次深度体检。