JMeter压测遇BindException及多核LG性能不及双核问题求助

1. LG2抛出Non HTTP response code: java.net.BindException的原因及解决办法 #

原因 #

• 本地端口耗尽：每个HTTP短连接会占用一个客户端临时端口，当并发请求量过大时，可用端口被全部占用，无法建立新连接。
• TIME_WAIT端口未及时释放：TCP连接关闭后，端口会进入TIME_WAIT状态默认保留1-2分钟，大量短连接快速关闭会导致这些端口无法被复用，进一步加剧端口不足。
• 系统TCP参数限制：多数操作系统默认的临时端口范围、TIME_WAIT相关参数设置保守，无法支撑高并发连接创建需求。

解决办法 #

• 调整系统TCP参数（以Linux为例）：
  • 扩大临时端口范围：执行echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf，再运行sysctl -p使配置生效，增加可用端口总量。
  • 开启TIME_WAIT端口复用：设置net.ipv4.tcp_tw_reuse = 1，允许将处于TIME_WAIT状态的端口复用给新的TCP连接。
  • 缩短TIME_WAIT超时：设置net.ipv4.tcp_fin_timeout = 30，减少端口在TIME_WAIT状态的停留时间。
• 优化JMeter请求配置：
  • 启用HTTP Keep-Alive：在HTTP请求的「高级」选项中勾选「使用Keep-Alive」，复用TCP连接，降低端口占用率。
  • 配置HTTP连接池：通过HTTP Request Defaults或Connection Configuration元件设置连接池大小，限制每个线程的连接数，避免无限制创建新连接。
• 调整线程启动策略：延长线程组的「Ramp-Up Period」（线程启动时间），避免瞬间启动大量线程导致端口被快速耗尽。

2. 为何4核的LG2性能不及2核的LG1 #

• 系统参数差异：LG2的默认系统配置（如TCP参数、文件句柄限制）可能比LG1更保守，比如临时端口范围更小、未开启TIME_WAIT复用，导致端口先耗尽，无法支撑更多VU。
• JVM配置不合理：LG2的JMeter JVM参数（如堆内存-Xmx、垃圾回收器选型）未优化，比如堆内存过小引发频繁GC，或垃圾回收器效率低下，占用大量CPU资源，拖累整体性能。
• 网络瓶颈：LG2的网络带宽不足、网卡驱动未优化，或存在网络延迟问题，导致请求无法及时收发，限制了并发VU的数量。
• 后台资源占用：LG2运行了防火墙、杀毒软件或其他后台服务，占用了大量CPU、内存或网络资源，使得JMeter无法充分利用硬件性能。
• CPU单核心性能差异：尽管LG2是4核，但如果其单核心主频远低于LG1（比如LG1是高频双核，LG2是低频四核），而JMeter的线程模型更依赖单线程处理能力，多核优势无法发挥，反而因线程切换开销导致性能下降。
• 测试脚本或环境差异：两台LG上的测试脚本可能存在差异（比如LG2的脚本包含更多复杂断言、前置/后置处理器），或LG2的测试环境存在额外依赖，导致每个VU的资源占用更高，无法达到更高并发数。

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