当前位置：首页 > news >正文

JMeter WebSocket多会话压测实战：从原理到脚本配置与瓶颈定位

news 2026/6/30 11:00:02

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，右键测试计划 -> 添加 -> 线程（用户） ->线程组。
配置线程组：
- 线程数（模拟用户数）：100
- Ramp-Up时间（秒）：10 （表示在10秒内启动全部100个线程，而不是瞬间启动，给服务器一个缓冲）
- 循环次数：5 （每个线程执行整个脚本5次。如果想长时间压测，可以勾选“永远”）

4.2 第二步：配置公共变量

右键线程组 -> 添加 -> 配置元件 ->用户定义的变量。添加以下变量，方便后续引用：

server:localhost
port:8080
path:/echo
connection_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，则填wss）
Read 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:MaxMetaspaceSize=1g。具体大小视你的测试规模和机器内存而定。
禁用图形界面（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. 常见问题与排查技巧实录

在实际操作中，你肯定会遇到各种问题。这里记录几个我踩过的坑和解决方法。

问题1：WebSocket连接建立失败，返回“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）都是一个文件描述符。
解决：
1. 增加系统限制：临时提高限制ulimit -n 65535。永久修改需要编辑/etc/security/limits.conf。
2. 使用分布式压测：这是解决单机JMeter瓶颈的根本方法。在一台控制机（Controller）上配置多台压力机（Agent）。压力机分担连接数。注意，WebSocket连接是有状态的，需要确保同一个虚拟用户的整个会话（Open， Request， Close）在同一个压力机上执行。JMeter的分布式测试需要做一些额外配置来保证这一点。
3. 优化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参数或数据库索引。

最后，记住压测的黄金法则：循序渐进，监控先行。不要一开始就上最大并发。从低并发开始，逐步增加，观察各项指标的变化曲线，找到系统的性能拐点和瓶颈点。每一次压测，目标不仅仅是得到一个“能扛多少并发”的数字，更是为了发现系统的弱点，并推动其优化。这个过程本身，就是对系统架构和理解的一次深度体检。

查看全文

http://www.jsqmd.com/news/1095495/