Jmeter常见压测错误解决

错误一：

Response code: Non HTTP response code: java.net.SocketTimeoutException

Response message: Non HTTP response message: connect timed out

原因：

查看Load time的时间要大于request设置的connect time out时间，因此抛出该异常。多是因为服务端有较多请求正在处理（且处理时间较长），致使JMeter不能链接上服务器而产生的

错误二：

Java.NET.BindException: Address already in use: connect缘由：短期内new socket操做不少,而socket.close()操做并不能当即释放绑定的端口,而是把端口设置为TIMEWAIT 状态,过段时间(默认240s)才释放,(用netstat -na能够看到),最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ,这段区间在1024-5000之间)

解决方法：

在运行JMeter agent的机器上，添加注册表条目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

MaxUserPort 65334

TcpTimedWaitDelay 30window

错误三：

java.lang.OutOfMemoryError: Java heap space

缘由：观察运行jmeter机器的内存，占用较高，超过了jmeter设置的内存上限。

解决方案：

修改jmeter配置文件，调整内存可用的范围服务器

修改/bin/jmeter.bat文件：找到这2行

set HEAP=-Xms256m -Xmx256m

set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m

改成：

set HEAP=-Xms1024m –Xmx2048m（最大值不能超过系统内存的1/2）

set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m网络

错误四：

Response code: Non HTTP response code: java.net.SocketTimeoutException

Response message: Non HTTP response message: Read timed out

发生该错误时，jmeter已经连接上服务器，查看load time没有超过设定的request timeout时间，错误可能的缘由是，服务器那边未处理该线程的请求，或者为保证服务能力，断掉了链接。

为了验证该猜测，持续大于半小时向服务器发送该并发数量的请求，一段时间后，request收到503的response，证实猜测。

错误五：

Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:

缘由：分布式测试时，server和agent之间的链接有问题。单个机器排查后，发现是某个agent机器安装了多个网卡，rmi远程的时候找的是虚拟机的网卡，致使链接失败。

解决方案：

禁掉不使用的虚拟机网卡，测试以后再恢复

错误六：

Connection timed out: connect工具

java.net.ConnectException: Connection timed out: connect

at java.net.DualStackPlainSocketImpl.connect0(

缘由分析：

多是由于端口号耗尽，通常一台服务器的端口号最可能是65535个，建议使用该命令分别查看下压测机与服务器的端口使用状况，netstat -nat|grep -i 8080|wc -l，若是这个个数在6w左右，那可能就是端口号用尽,同时查看下大多数的端口状态，应该都是time_wait状态

解决方案：

若是是压测机，端口号用尽，那就增长压测机，使用jmeter分布式压测（jmeter默认开启keep_alive的）

若是数服务器，端口号用尽，最大的多是服务器端开了短连接，把短连接配置变成长链接便可

由于若是服务器端是短连接，当jmeter每发起一个请求就会创建一次tcp三次握手，传输完数据后，链接其实没有关，链接状态是time_wait,下个请求来了，会从新开启一个新的端口，创建tcp三次握手，传输数据....，这样随着请求的愈来愈多，端口就会变得愈来愈少，因此端口很快耗尽，并且大多数端口都处于time_wait状态,若是服务器端也支持长链接，那么下次请求来了，就会在上次请求的通道上继续传输，端口使用率大大的下降，就有效的避免了端口耗尽问题。

常规操作，每个请求可以给个超时时间，避免http超时错误