如何借助JMeter与Concurrency Thread Group实现稳定吞吐量？

针对你遇到的长时间运行后RPS低于预期、频繁出现java.net.SocketException: Socket closed的问题，可按以下步骤排查解决：

1. 排查服务器端连接限制与超时配置 #

服务器可能因连接超时、最大连接数限制主动关闭连接：

• 检查服务器日志（如Nginx、Tomcat等），确认是否有连接超时、连接数耗尽的记录；
• 核实服务器的keepalive_timeout设置，若超时时间过短，会导致空闲连接被主动关闭，引发Socket Closed错误；
• 确认服务器是否有并发连接数上限，若达到上限，新请求会被拒绝或连接被关闭。

2. 优化JMeter HTTP连接池配置 #

默认的HTTP连接池设置可能不适合长时间运行的压测，调整以下参数：

• 在HTTP请求的Advanced标签中，强制设置Connection: keep-alive，确保连接复用；
• 修改JMeter安装目录下的user.properties文件，添加或调整：

  # 连接重试次数
  httpclient4.retrycount=1
  # 空闲连接超时时间（毫秒），建议设置为服务器keepalive_timeout的一半
  httpclient4.idletimeout=30000
  # 连接建立超时时间
  httpclient4.connection_timeout=10000
  # 最大连接数
  httpclient4.max_total=200
  # 每个主机的最大连接数
  httpclient4.max_per_route=100
  

3. 调整tstFeedback函数参数 #

当前tstFeedback(tst,13,50,10)的步长（10）可能过小，导致JMeter无法快速调整并发数维持RPS：

• 增大步长值（如调整为20），让JMeter在RPS下降时更快增加线程数；
• 适当提高最小并发数（如从13调整为15），确保初始并发足够支撑长时间运行的负载；
• 确认Throughput Shaping Timer的作用域是否覆盖所有必要的请求，避免部分请求未被纳入吞吐量控制。

4. 监控并优化测试机资源 #

即使实例规格足够，长时间运行仍可能出现资源瓶颈：

• 用top、vmstat、iftop等命令监控CPU、内存、网络带宽使用率：
  • 若CPU使用率持续高于90%，说明JMeter无法生成足够请求，可考虑拆分压测任务或升级实例；
  • 若网络带宽饱和，需检查是否有不必要的日志输出或数据传输，减少资源消耗；
• 强制使用JMeter CLI模式运行（jmeter -n -t testplan.jmx -l result.jtl），避免GUI占用额外资源；
• 降低日志级别，仅保留ERROR级别的日志，减少磁盘IO开销。

5. 调整系统TCP内核参数 #

Ubuntu系统默认TCP参数可能不适合高并发压测，优化以下参数（临时生效，需写入/etc/sysctl.conf永久生效）：

# 允许复用TIME_WAIT状态的连接
sysctl -w net.ipv4.tcp_tw_reuse=1
# 加速TIME_WAIT连接回收
sysctl -w net.ipv4.tcp_fin_timeout=30
# 增大监听队列上限
sysctl -w net.core.somaxconn=2048
# 增大TCP接收/发送缓冲区
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

6. 升级插件与排查内存泄漏 #

• 检查Concurrency Thread Group和Throughput Shaping Timer插件版本，升级至对应JMeter 5.5的最新稳定版，避免旧版本的内存泄漏或逻辑bug；
• 使用jmap -heap <JMeter进程ID>分析堆内存使用，确认是否存在内存泄漏；用jstack <JMeter进程ID>查看线程状态，排查是否有线程阻塞情况。

7. 分段运行测试 #

若长时间运行必然出现资源累积，可将压测任务拆分为多个分段，每段运行后重启JMeter，避免资源耗尽导致的性能下降。

内容的提问来源于stack exchange，提问作者abbood