1. 从一次压测需求说起当JMeter遇上SSE最近在做一个金融数据实时推送项目的性能评估后端用的是Spring Boot通过SSEServer-Sent Events协议向客户端推送实时行情。项目上线前我们自然要对这个长链接接口进行压测看看它在高并发下的表现。团队里第一个想到的工具就是JMeter毕竟它是性能测试领域的“瑞士军刀”HTTP请求、数据库、消息队列啥的都能测。但当我们把SSE接口的URL填进HTTP请求采样器设置好线程数开跑后结果却让人大跌眼镜几乎所有的请求都失败了或者很快就断开了完全模拟不出大量客户端长连接挂在那持续接收数据的场景。这个问题其实挺典型的。很多朋友在用JMeter做接口测试时习惯性地把它当作一个“发请求-收响应”的短连接工具。但SSE、WebSocket这类长连接协议核心在于“连接保持”和“事件流持续接收”这与传统的请求-响应模式有本质区别。JMeter的默认HTTP采样器是为短连接设计的它在收到一个响应哪怕是Transfer-Encoding: chunked的流式响应后就会认为这个请求事务结束了从而关闭连接这显然不符合SSE的要求。所以这篇内容就来详细聊聊怎么让JMeter这个“短跑健将”去跑“长跑比赛”也就是如何正确地压测SSE长链接接口。我们会从SSE协议的原理讲起分析JMeter默认行为为什么不适用然后给出两种经过实战验证的解决方案最后还会分享一些压测过程中的观察要点和避坑经验。无论你是要对消息推送、实时监控还是类似的长连接服务进行压力测试这些思路都能用得上。2. 理解核心SSE协议与JMeter默认行为的冲突要想解决问题得先搞清楚问题出在哪。SSE和JMeter的默认逻辑在几个关键点上完全是“鸡同鸭讲”。2.1 SSE协议的工作机制不止是“连接”SSE是一种允许服务器向客户端单向推送数据的HTML5技术。它的工作流程可以概括为建立连接客户端通常是浏览器通过一个普通的HTTP GET请求连接到服务器的一个特定端点。保持连接服务器在响应时必须将Content-Type设置为text/event-stream。并且服务器不会立即关闭这个HTTP连接而是将其保持为打开状态。流式推送连接建立后服务器可以随时通过这个持久的连接向客户端发送遵循特定格式的数据块。每个数据块以“data: ”开头以两个换行符“\n\n”结束。例如data: 这是一条消息\n\n data: {time: 2023-10-27, price: 100.5}\n\n客户端处理客户端的EventSourceAPI会持续监听这个连接每当收到一个完整的data块就会触发一个消息事件。连接终止连接会一直保持直到客户端或服务器主动关闭它。关键点在于这是一个长期存活的HTTP连接响应体是“无限长”的流。服务器会周期性地发送“心跳”比如注释行: keepalive\n\n来防止代理或防火墙超时断开连接。2.2 JMeter HTTP采样器的“短视”行为现在我们看看JMeter的HTTP请求采样器在默认配置下是怎么干的发送请求它向目标URL发送一个HTTP请求。接收响应它开始接收响应头然后接收响应体。判断结束对于普通的HTTP响应当接收到完整的响应体由Content-Length头指定长度或遇到chunked编码的结束块后JMeter就认为这个请求-响应事务完成了。关闭连接事务完成JMeter会关闭底层的TCP连接释放资源然后这个线程可能去执行下一个采样器或者循环。矛盾立刻出现了SSE服务器的响应体在理论上永不结束没有最终的Content-Lengthchunked流也会一直持续。JMeter在等待一个“结束信号”但这个信号永远不会来。因此可能会出现以下几种情况超时断开JMeter有一个“响应超时”设置默认可能未显式设置但底层有超时机制。等待一段时间后没看到响应结束JMeter会断开连接并可能将这次请求标记为超时失败。读取中断即使连接没断JMeter在读取一段时间后也可能因为内部缓冲区或策略而停止读取并关闭连接这无法模拟真实客户端长期监听的行为。无法统计由于请求事务无法正常结束JMeter可能无法正确记录响应时间、吞吐量等关键指标。简单说用默认的HTTP采样器压测SSE就像用秒表去测量一场不知道终点的马拉松秒表迟早会自己停掉然后宣布“比赛超时”。这完全扭曲了压测的本意。3. 解决方案一使用“流”式处理的HTTP采样器既然问题出在JMeter过早关闭连接那么最直接的思路就是告诉JMeter“这个连接你别关一直给我读下去”。幸运的是JMeter提供了支持这种模式的选项。3.1 关键配置Use KeepAlive与Response Timeout首先在HTTP请求采样器的“高级”标签页里有几个关键配置Use KeepAlive这个必须勾选。它指示JMeter在请求完成后尝试重用连接。虽然SSE场景下连接不会“完成”但勾选此选项是保持连接活跃的必要基础。Response Timeout这是需要重点调整的参数。默认可能是空白的。对于SSE压测你必须将其设置为一个足够大的值比如300000300秒5分钟甚至更长具体取决于你计划压测的持续时间。这个超时指的是“等待响应结束”的超时设置得足够长JMeter就不会因为等不到结束而主动断开。你可以将其设置为与你的测试持续时间相同或更长。Implementation通常使用默认的HttpClient4或Java即可它们都支持长连接。注意仅仅设置一个大超时并不能完全模拟真实客户端。因为真实客户端如浏览器EventSource是主动持续读取数据流而JMeter的HTTP采样器在读取到一些数据后可能仍然会进入“等待响应结束”的阻塞状态而不是持续触发消息接收事件。这对于只需要测试连接承载能力而对消息接收频率不敏感的场景可能够用但不够精确。3.2 更专业的处理使用“Streaming”主体处理方式在HttpClient4的实现中提供了一个更接近SSE客户端行为的选项。在HTTP请求的“高级”标签页最下方找到“客户端实现”选择HttpClient4后旁边会出现一个“超时”定义按钮点进去会有更多高级设置。但更有效的方法是在HTTP请求的“消息体数据”标签页与“参数”、“文件上传”同级中注意底部有一个不太起眼的选项“将响应保存为消息体数据”。然而我们需要的不是这个。真正关键的是通过后置处理器或使用BeanShell/JSR223采样器来模拟流式读取。不过这涉及编写脚本复杂度较高。因此对于大多数场景我推荐下面这种更优雅、更专业的解决方案。4. 解决方案二采用专为SSE/WebSocket设计的插件社区的力量是强大的。JMeter有丰富的插件生态系统其中就有专门用于处理长连接协议的插件。使用插件可以更真实地模拟客户端行为并且配置起来更直观。4.1 插件安装JMeter Plugins Manager首先你需要安装JMeter的插件管理器。访问https://jmeter-plugins.org/网站下载plugins-manager.jar文件将其放入JMeter安装目录的lib/ext文件夹中然后重启JMeter。重启后你可以在“选项”菜单中找到“Plugins Manager”。4.2 推荐插件WebSocket Samplersby Peter Doornbosch虽然名字叫WebSocket但这个插件包里的“HTTP2/SSE”采样器正是我们需要的。在Plugins Manager中搜索“WebSocket”找到“WebSocket Samplers by Peter Doornbosch”并进行安装。安装后需要再次重启JMeter。4.3 配置SSE采样器进行压测重启后在线程组上右键添加采样器你会发现多出了“WebSocket”和“HTTP2/SSE”相关的选项。我们选择“HTTP2/SSE”。这个采样器的配置界面非常直观Server Name or IP服务器地址。Port Number端口号。PathSSE接口的路径。Implementation选择SSE。Read Timeout读取超时。这里的概念与之前不同它指的是每次尝试读取消息时的等待超时而不是连接总超时。可以设置一个较小的值如5000毫秒如果一段时间内没有消息它会超时并进入下一次读取循环而不会断开连接。Connection Timeout连接建立超时。Log Level日志级别调试时可设为DEBUG。配置好后这个采样器会建立到SSE端点的HTTP连接。保持连接打开。持续异步地读取从服务器推送过来的事件消息。每读取到一条完整的消息以\n\n结尾就可以触发后置处理器如JSON提取器来提取数据或者通过断言进行验证。连接会一直保持直到你设置的线程组循环结束或持续时间到达。这才是压测SSE接口的正确姿势。你可以像往常一样设置线程数模拟用户数和循环次数/持续时间每个线程虚拟用户都会独立维持一个SSE连接并持续接收消息。5. 压测场景设计与关键指标观察工具搞定了接下来就是设计有意义的压测场景。压测SSE接口我们关注的点与普通API有所不同。5.1 核心场景设计连接建立能力模拟大量客户端同时发起SSE连接。设置线程数如1000Ramp-up period设为0或很短观察服务器能否快速、成功地接受所有连接。这个场景主要测试服务器的连接处理能力和资源如文件描述符是否充足。长连接维持能力模拟已建立的连接长时间保持。设置较长的测试持续时间如10分钟并发数维持在一个水平。观察在测试期间连接是否有异常断开通过检查响应代码或断言。这个场景测试服务器的连接保持能力、内存管理以及是否有内存泄漏。消息推送吞吐量在连接保持期间服务器会持续推送消息。我们需要关注服务器向所有连接广播消息时的性能。可以监控服务器的CPU、网络出口带宽。在JMeter中虽然SSE采样器主要接收但我们可以通过其他采样器如常规HTTP请求模拟触发服务器广播事件来测试这个场景。混合场景最接近真实的情况。模拟连接不断新加入、旧连接保持、同时持续接收消息的混合场景。可以设置一个稳定的并发数并让线程在运行一段时间后正常退出通过调度器或循环控制同时可能有新线程启动。5.2 关键监控指标JMeter端连接成功率最重要的指标之一。在“聚合报告”中查看“错误率”。任何非200的响应或连接失败都会计入错误。活跃线程数确保在整个测试期间预期的并发连接数一直保持着。吞吐量Throughput这里指每秒接收的事件数。这需要借助后置处理器提取消息并通过“事务控制器”或自定义方式来计算。这个指标直接反映了服务器推送消息的能力。响应时间对于SSE第一个响应连接建立的响应时间有意义。对于后续消息更关心消息从服务器发出到客户端收到的延迟这需要客户端和服务器时间戳配合计算在JMeter中实现较复杂通常需要结合业务日志。服务器端必须监控系统资源CPU使用率、内存使用量特别是堆内存和非堆内存、网络连接数netstat或ss命令、文件描述符使用量。应用指标活跃连接数应与JMeter的活跃线程数趋势一致。消息推送队列长度如果使用如果消息生产速度大于推送速度队列会堆积。GC情况长时间维持大量长连接对象容易引发GC问题特别是Full GC。线程池状态处理SSE连接的线程池是否健康。6. 实战避坑与经验总结在实际操作中会遇到一些预料之外的问题。这里分享几个常见的坑和应对策略。6.1 连接数上不去可能是本地端口耗尽当你模拟的并发数较高例如几千时可能会发现连接数在达到某个值如28232后就无法再建立新连接并且错误日志中可能出现“Address already in use: connect”之类的错误。原因这是客户端即运行JMeter的机器的问题。每个向外建立的TCP连接都需要占用一个本地端口ephemeral port。操作系统可用端口范围是有限的通常约28000个。当端口被快速占用且处于TIME_WAIT状态时新连接就会因没有可用端口而失败。解决方案增加本地端口范围Linux/macOS# 临时生效 sudo sysctl -w net.ipv4.ip_local_port_range1024 65535 # 永久生效编辑 /etc/sysctl.conf启用端口快速回收与重用Linuxsudo sysctl -w net.ipv4.tcp_tw_reuse1 sudo sysctl -w net.ipv4.tcp_tw_recycle1 # 注意在较新内核中可能已废弃或不建议使用 sudo sysctl -w net.ipv4.tcp_fin_timeout30使用分布式压测这是解决该问题最根本的方法。将压力分摊到多台JMeter Slave机器上每台机器只需要承担一部分连接数。使用JMeter的分布式压测功能。对服务器进行压测时确保JMeter机器本身的资源CPU、内存、网络足够避免成为瓶颈。6.2 服务器连接数上不去检查服务器限制连接数在服务器端也可能遇到瓶颈。操作系统限制检查服务器的最大文件描述符限制ulimit -n和最大用户进程数。SSE长连接会占用文件描述符。中间件/框架限制以Spring Boot内嵌Tomcat为例需要调整以下配置application.properties或application.yml# 增加最大连接数 server.tomcat.max-connections10000 # 增加最大线程数处理请求的线程与连接数不同 server.tomcat.max-threads200 # 调整连接超时等 server.tomcat.connection-timeout60000应用层设计确保你的服务端代码没有在内存中持有过多的连接引用导致OOM。考虑使用SseEmitter的超时和完成回调及时清理资源。6.3 消息丢失或顺序错乱理解SSE的可靠性SSE协议基于HTTP本身不提供像TCP那样的强可靠性保证。如果网络抖动导致连接断开客户端需要自动重连。在压测中你可能看到一些连接中断然后重连的情况这是正常的。在JMeter中使用HTTP2/SSE插件时可以配置重连逻辑。在你的实际业务客户端中EventSourceAPI有自动重连机制但重连后如何获取错过的消息如从上次断开的消息ID开始需要服务端设计支持比如在事件中包含ID。6.4 性能指标解读别只看平均响应时间对于SSE这类长连接服务平均响应时间这个指标价值不大因为连接建立后的大部分时间都在等待。更应该关注的是错误率是否在可接受范围内如0.1%。连接稳定性在整个压测周期内活跃连接数的曲线是否平稳有无大幅下跌代表大量连接异常断开。服务器资源水位CPU、内存、GC是否平稳有无持续增长的趋势可能预示内存泄漏。消息端到端延迟如果可测量在消息产生后到达所有客户端的时间分布P50, P95, P99。最后压测SSE接口的核心思想是模拟真实客户端的长期持有连接并接收事件流的行为。抛弃默认的短连接思维选用合适的工具如HTTP2/SSE插件和方法设计合理的场景并全面监控客户端与服务端的指标才能真正评估出你的实时推送服务在高并发下的健壮性。从我的经验来看很多性能问题往往出现在连接数达到一定量级之后因此阶梯式增压逐步增加并发数的测试方法比一开始就进行极限施压更能帮助你发现系统的性能拐点和瓶颈所在。 
长河君 · 2026/8/7 3:54:15 · 阅读 1.2k JMeter压测SSE长连接接口：从协议冲突到实战解决方案
1. 从一次压测需求说起当JMeter遇上SSE最近在做一个金融数据实时推送项目的性能评估后端用的是Spring Boot通过SSEServer-Sent Events协议向客户端推送实时行情。项目上线前我们自然要对这个长链接接口进行压测看看它在高并发下的表现。团队里第一个想到的工具就是JMeter毕竟它是性能测试领域的“瑞士军刀”HTTP请求、数据库、消息队列啥的都能测。但当我们把SSE接口的URL填进HTTP请求采样器设置好线程数开跑后结果却让人大跌眼镜几乎所有的请求都失败了或者很快就断开了完全模拟不出大量客户端长连接挂在那持续接收数据的场景。这个问题其实挺典型的。很多朋友在用JMeter做接口测试时习惯性地把它当作一个“发请求-收响应”的短连接工具。但SSE、WebSocket这类长连接协议核心在于“连接保持”和“事件流持续接收”这与传统的请求-响应模式有本质区别。JMeter的默认HTTP采样器是为短连接设计的它在收到一个响应哪怕是Transfer-Encoding: chunked的流式响应后就会认为这个请求事务结束了从而关闭连接这显然不符合SSE的要求。所以这篇内容就来详细聊聊怎么让JMeter这个“短跑健将”去跑“长跑比赛”也就是如何正确地压测SSE长链接接口。我们会从SSE协议的原理讲起分析JMeter默认行为为什么不适用然后给出两种经过实战验证的解决方案最后还会分享一些压测过程中的观察要点和避坑经验。无论你是要对消息推送、实时监控还是类似的长连接服务进行压力测试这些思路都能用得上。2. 理解核心SSE协议与JMeter默认行为的冲突要想解决问题得先搞清楚问题出在哪。SSE和JMeter的默认逻辑在几个关键点上完全是“鸡同鸭讲”。2.1 SSE协议的工作机制不止是“连接”SSE是一种允许服务器向客户端单向推送数据的HTML5技术。它的工作流程可以概括为建立连接客户端通常是浏览器通过一个普通的HTTP GET请求连接到服务器的一个特定端点。保持连接服务器在响应时必须将Content-Type设置为text/event-stream。并且服务器不会立即关闭这个HTTP连接而是将其保持为打开状态。流式推送连接建立后服务器可以随时通过这个持久的连接向客户端发送遵循特定格式的数据块。每个数据块以“data: ”开头以两个换行符“\n\n”结束。例如data: 这是一条消息\n\n data: {time: 2023-10-27, price: 100.5}\n\n客户端处理客户端的EventSourceAPI会持续监听这个连接每当收到一个完整的data块就会触发一个消息事件。连接终止连接会一直保持直到客户端或服务器主动关闭它。关键点在于这是一个长期存活的HTTP连接响应体是“无限长”的流。服务器会周期性地发送“心跳”比如注释行: keepalive\n\n来防止代理或防火墙超时断开连接。2.2 JMeter HTTP采样器的“短视”行为现在我们看看JMeter的HTTP请求采样器在默认配置下是怎么干的发送请求它向目标URL发送一个HTTP请求。接收响应它开始接收响应头然后接收响应体。判断结束对于普通的HTTP响应当接收到完整的响应体由Content-Length头指定长度或遇到chunked编码的结束块后JMeter就认为这个请求-响应事务完成了。关闭连接事务完成JMeter会关闭底层的TCP连接释放资源然后这个线程可能去执行下一个采样器或者循环。矛盾立刻出现了SSE服务器的响应体在理论上永不结束没有最终的Content-Lengthchunked流也会一直持续。JMeter在等待一个“结束信号”但这个信号永远不会来。因此可能会出现以下几种情况超时断开JMeter有一个“响应超时”设置默认可能未显式设置但底层有超时机制。等待一段时间后没看到响应结束JMeter会断开连接并可能将这次请求标记为超时失败。读取中断即使连接没断JMeter在读取一段时间后也可能因为内部缓冲区或策略而停止读取并关闭连接这无法模拟真实客户端长期监听的行为。无法统计由于请求事务无法正常结束JMeter可能无法正确记录响应时间、吞吐量等关键指标。简单说用默认的HTTP采样器压测SSE就像用秒表去测量一场不知道终点的马拉松秒表迟早会自己停掉然后宣布“比赛超时”。这完全扭曲了压测的本意。3. 解决方案一使用“流”式处理的HTTP采样器既然问题出在JMeter过早关闭连接那么最直接的思路就是告诉JMeter“这个连接你别关一直给我读下去”。幸运的是JMeter提供了支持这种模式的选项。3.1 关键配置Use KeepAlive与Response Timeout首先在HTTP请求采样器的“高级”标签页里有几个关键配置Use KeepAlive这个必须勾选。它指示JMeter在请求完成后尝试重用连接。虽然SSE场景下连接不会“完成”但勾选此选项是保持连接活跃的必要基础。Response Timeout这是需要重点调整的参数。默认可能是空白的。对于SSE压测你必须将其设置为一个足够大的值比如300000300秒5分钟甚至更长具体取决于你计划压测的持续时间。这个超时指的是“等待响应结束”的超时设置得足够长JMeter就不会因为等不到结束而主动断开。你可以将其设置为与你的测试持续时间相同或更长。Implementation通常使用默认的HttpClient4或Java即可它们都支持长连接。注意仅仅设置一个大超时并不能完全模拟真实客户端。因为真实客户端如浏览器EventSource是主动持续读取数据流而JMeter的HTTP采样器在读取到一些数据后可能仍然会进入“等待响应结束”的阻塞状态而不是持续触发消息接收事件。这对于只需要测试连接承载能力而对消息接收频率不敏感的场景可能够用但不够精确。3.2 更专业的处理使用“Streaming”主体处理方式在HttpClient4的实现中提供了一个更接近SSE客户端行为的选项。在HTTP请求的“高级”标签页最下方找到“客户端实现”选择HttpClient4后旁边会出现一个“超时”定义按钮点进去会有更多高级设置。但更有效的方法是在HTTP请求的“消息体数据”标签页与“参数”、“文件上传”同级中注意底部有一个不太起眼的选项“将响应保存为消息体数据”。然而我们需要的不是这个。真正关键的是通过后置处理器或使用BeanShell/JSR223采样器来模拟流式读取。不过这涉及编写脚本复杂度较高。因此对于大多数场景我推荐下面这种更优雅、更专业的解决方案。4. 解决方案二采用专为SSE/WebSocket设计的插件社区的力量是强大的。JMeter有丰富的插件生态系统其中就有专门用于处理长连接协议的插件。使用插件可以更真实地模拟客户端行为并且配置起来更直观。4.1 插件安装JMeter Plugins Manager首先你需要安装JMeter的插件管理器。访问https://jmeter-plugins.org/网站下载plugins-manager.jar文件将其放入JMeter安装目录的lib/ext文件夹中然后重启JMeter。重启后你可以在“选项”菜单中找到“Plugins Manager”。4.2 推荐插件WebSocket Samplersby Peter Doornbosch虽然名字叫WebSocket但这个插件包里的“HTTP2/SSE”采样器正是我们需要的。在Plugins Manager中搜索“WebSocket”找到“WebSocket Samplers by Peter Doornbosch”并进行安装。安装后需要再次重启JMeter。4.3 配置SSE采样器进行压测重启后在线程组上右键添加采样器你会发现多出了“WebSocket”和“HTTP2/SSE”相关的选项。我们选择“HTTP2/SSE”。这个采样器的配置界面非常直观Server Name or IP服务器地址。Port Number端口号。PathSSE接口的路径。Implementation选择SSE。Read Timeout读取超时。这里的概念与之前不同它指的是每次尝试读取消息时的等待超时而不是连接总超时。可以设置一个较小的值如5000毫秒如果一段时间内没有消息它会超时并进入下一次读取循环而不会断开连接。Connection Timeout连接建立超时。Log Level日志级别调试时可设为DEBUG。配置好后这个采样器会建立到SSE端点的HTTP连接。保持连接打开。持续异步地读取从服务器推送过来的事件消息。每读取到一条完整的消息以\n\n结尾就可以触发后置处理器如JSON提取器来提取数据或者通过断言进行验证。连接会一直保持直到你设置的线程组循环结束或持续时间到达。这才是压测SSE接口的正确姿势。你可以像往常一样设置线程数模拟用户数和循环次数/持续时间每个线程虚拟用户都会独立维持一个SSE连接并持续接收消息。5. 压测场景设计与关键指标观察工具搞定了接下来就是设计有意义的压测场景。压测SSE接口我们关注的点与普通API有所不同。5.1 核心场景设计连接建立能力模拟大量客户端同时发起SSE连接。设置线程数如1000Ramp-up period设为0或很短观察服务器能否快速、成功地接受所有连接。这个场景主要测试服务器的连接处理能力和资源如文件描述符是否充足。长连接维持能力模拟已建立的连接长时间保持。设置较长的测试持续时间如10分钟并发数维持在一个水平。观察在测试期间连接是否有异常断开通过检查响应代码或断言。这个场景测试服务器的连接保持能力、内存管理以及是否有内存泄漏。消息推送吞吐量在连接保持期间服务器会持续推送消息。我们需要关注服务器向所有连接广播消息时的性能。可以监控服务器的CPU、网络出口带宽。在JMeter中虽然SSE采样器主要接收但我们可以通过其他采样器如常规HTTP请求模拟触发服务器广播事件来测试这个场景。混合场景最接近真实的情况。模拟连接不断新加入、旧连接保持、同时持续接收消息的混合场景。可以设置一个稳定的并发数并让线程在运行一段时间后正常退出通过调度器或循环控制同时可能有新线程启动。5.2 关键监控指标JMeter端连接成功率最重要的指标之一。在“聚合报告”中查看“错误率”。任何非200的响应或连接失败都会计入错误。活跃线程数确保在整个测试期间预期的并发连接数一直保持着。吞吐量Throughput这里指每秒接收的事件数。这需要借助后置处理器提取消息并通过“事务控制器”或自定义方式来计算。这个指标直接反映了服务器推送消息的能力。响应时间对于SSE第一个响应连接建立的响应时间有意义。对于后续消息更关心消息从服务器发出到客户端收到的延迟这需要客户端和服务器时间戳配合计算在JMeter中实现较复杂通常需要结合业务日志。服务器端必须监控系统资源CPU使用率、内存使用量特别是堆内存和非堆内存、网络连接数netstat或ss命令、文件描述符使用量。应用指标活跃连接数应与JMeter的活跃线程数趋势一致。消息推送队列长度如果使用如果消息生产速度大于推送速度队列会堆积。GC情况长时间维持大量长连接对象容易引发GC问题特别是Full GC。线程池状态处理SSE连接的线程池是否健康。6. 实战避坑与经验总结在实际操作中会遇到一些预料之外的问题。这里分享几个常见的坑和应对策略。6.1 连接数上不去可能是本地端口耗尽当你模拟的并发数较高例如几千时可能会发现连接数在达到某个值如28232后就无法再建立新连接并且错误日志中可能出现“Address already in use: connect”之类的错误。原因这是客户端即运行JMeter的机器的问题。每个向外建立的TCP连接都需要占用一个本地端口ephemeral port。操作系统可用端口范围是有限的通常约28000个。当端口被快速占用且处于TIME_WAIT状态时新连接就会因没有可用端口而失败。解决方案增加本地端口范围Linux/macOS# 临时生效 sudo sysctl -w net.ipv4.ip_local_port_range1024 65535 # 永久生效编辑 /etc/sysctl.conf启用端口快速回收与重用Linuxsudo sysctl -w net.ipv4.tcp_tw_reuse1 sudo sysctl -w net.ipv4.tcp_tw_recycle1 # 注意在较新内核中可能已废弃或不建议使用 sudo sysctl -w net.ipv4.tcp_fin_timeout30使用分布式压测这是解决该问题最根本的方法。将压力分摊到多台JMeter Slave机器上每台机器只需要承担一部分连接数。使用JMeter的分布式压测功能。对服务器进行压测时确保JMeter机器本身的资源CPU、内存、网络足够避免成为瓶颈。6.2 服务器连接数上不去检查服务器限制连接数在服务器端也可能遇到瓶颈。操作系统限制检查服务器的最大文件描述符限制ulimit -n和最大用户进程数。SSE长连接会占用文件描述符。中间件/框架限制以Spring Boot内嵌Tomcat为例需要调整以下配置application.properties或application.yml# 增加最大连接数 server.tomcat.max-connections10000 # 增加最大线程数处理请求的线程与连接数不同 server.tomcat.max-threads200 # 调整连接超时等 server.tomcat.connection-timeout60000应用层设计确保你的服务端代码没有在内存中持有过多的连接引用导致OOM。考虑使用SseEmitter的超时和完成回调及时清理资源。6.3 消息丢失或顺序错乱理解SSE的可靠性SSE协议基于HTTP本身不提供像TCP那样的强可靠性保证。如果网络抖动导致连接断开客户端需要自动重连。在压测中你可能看到一些连接中断然后重连的情况这是正常的。在JMeter中使用HTTP2/SSE插件时可以配置重连逻辑。在你的实际业务客户端中EventSourceAPI有自动重连机制但重连后如何获取错过的消息如从上次断开的消息ID开始需要服务端设计支持比如在事件中包含ID。6.4 性能指标解读别只看平均响应时间对于SSE这类长连接服务平均响应时间这个指标价值不大因为连接建立后的大部分时间都在等待。更应该关注的是错误率是否在可接受范围内如0.1%。连接稳定性在整个压测周期内活跃连接数的曲线是否平稳有无大幅下跌代表大量连接异常断开。服务器资源水位CPU、内存、GC是否平稳有无持续增长的趋势可能预示内存泄漏。消息端到端延迟如果可测量在消息产生后到达所有客户端的时间分布P50, P95, P99。最后压测SSE接口的核心思想是模拟真实客户端的长期持有连接并接收事件流的行为。抛弃默认的短连接思维选用合适的工具如HTTP2/SSE插件和方法设计合理的场景并全面监控客户端与服务端的指标才能真正评估出你的实时推送服务在高并发下的健壮性。从我的经验来看很多性能问题往往出现在连接数达到一定量级之后因此阶梯式增压逐步增加并发数的测试方法比一开始就进行极限施压更能帮助你发现系统的性能拐点和瓶颈所在。