Jmeter自动化性能测试常见问题

　　一、request 请求超时设置

　　timeout 超时时间是可以手动设置的，新建一个 http 请求，在“高级”设置中找到“超时”设置，设置连接、响应时间为2000ms。

　　1. 请求连接超时，连不上服务器。

　　Jmeter表现形式为：前面几个请求是成功的，但是后面请求有的会报错，有的请求成功

　　报错1:

　　原因：

　　一般是因为线程太多，connection time out error 服务器请求太多了，处理不过来。

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

　　解决方法：设置 jmeter http 请求超时conn，重启server

　　原因：

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

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

　　如果服务器端是短连接，当 jmeter 每发起一个请求就会创建一次 tcp 三次握手，传输完数据后，链接其实没有关，链接状态是 time_wait，下个请求来了会重新开启一个新的端口，创建tcp三次握手，传输数据....

　　这样随着请求的愈来愈多，端口就会变得愈来愈少，因此端口很快耗尽，并且大多数端口都处于 time_wait 状态，若是服务器端也支持长链接，那么下次请求来了，就会在上次请求的通道上继续传输，端口使用率大大的下降，就有效的避免了端口耗尽问题。常规操作，每个请求可以给个超时时间，避免 http 超时错误。

　　2. 连接成功，但是读取超时。

　　等不到服务器返回的数据，一般是这次请求查询的量很大，比如查了5度的顶点。（timeout 小于 server 的最大等待时间）read time out error

　　jmeter等不到服务器返回的数据就断开了请求。

　　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，证实猜测。

　　3. 连接成功，server查询数据时超时

　　是因为2中请求的导致的 server 超时机制，如果查询时间超过 30s 自动报错。（timeout大于server的等待时间），在2的基础上，已经设置很大的响应时间了，但是还是 timeout，这个应该就是 server 等不到数据库返回的数据超时了。

　　二、压力机自身存在的问题

　　1.在网络编程中，特别是在短时间内新建的网络连接太多，经常出现

　　java.net.BindException: Address already in use: JVM_Bind的异常

　　Java.NET.BindException: Address already in use: connect

　　原因：

　　短期内新建 socket 操作太多，而 socket.close() 操作并不能当即释放绑定的端口，而是把端口设置为 time_wait 状态，过段时间(默认240s)才释放，用netstat -na能够看到，最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ，这段区间在1024-5000之间)

　　解决方法：

　　在运行 jmeter agent 的机器上，添加注册表条目

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　MaxUserPort 65334

　　TcpTimedWaitDelay 30

　　jmeter工具运行设置：

　　1. cmd中，用 regedit 命令打开注册表

　　2. 在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　3. 右键Parameters

　　4. 新建DWORD值，（十进制）设置为30秒。名称:TcpTimedWaitDelay,值:30。新建DWORD值，（十进制）最大连接数65534。名称:MaxUserPort,值:65534

　　5. 基数选择十进制；以增大可分配的 tcp 连接端口数、减小处于 TIME_WAIT 状态的连接的生存时间

　　6. 修改配置完毕之后记得重启机器才会生效

　　jmeter 发送请求后返回java.net.SocketException: Connection reset

　　这表明是测试服务器有问题，可以去页面验证下。有可能是要配置客户端的设置，如上面的工具运行设置。

　　java.net.SocketException: Socket closed

　　step1:

　　在 http 请求里面找到高级 implementation 选择 httpclient 4，connect设置为15000-300000毫秒。

　　step2:

　　在 jmeter 安装目录的 bin 目录下，找到 jmeter.properties 并打开。打开425行的注释，值设置为1：

　　原因：

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

　　解决方案：

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

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

　　改成：

　　如遇到上面请求返回的reponse, 就要首先去服务器端的日志，通过日志来定位问题

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

　　原因：

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

　　解决方案：

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

　　原因：

　　jmeter 是一个纯 java 开发的工具，内存由 java 虚拟机 JVM 管理，当内存回收不及时，堆内存不足时，就会报内存溢出错误。

　　概念补充：

　　内存泄露：应用使用资源之后没有及时释放，导致应用内存中持有了不需要的资源。

　　内存溢出：应用的内存已经不能满足正常使用了，堆栈已经达到系统设置的最大值，进而导致崩溃。

　　通常都是由于内存泄露导致堆栈内存不断增大，从而引发内存溢出。对 jmeter 而言也是如此，jmeter 测试过程中，如果内存溢出的话，一般会出现上面的提示：java.lang.OutOfMemoryError: Java heap space意思就是堆内存溢出，不够用了

　　解决方法：

　　知道了报错出现的原因是因为堆内存大小不足引起的，自然而然就会想到内存溢出的解决方法：调整堆内存大小。

　　步骤（以Windows系统为例，Linux系统类似）：

　　1. 打开jmeter.bat文件，按关键字“HEAP”搜索，把原来的配置改为如下：修改前：

　　修改后：

　　PS：

　　这个值不是越大越好，要根据压测使用的机器而定，一般而言，堆内存的最大值不要超过物理内存的一半，否则容易导致 jmeter 运行变慢、卡顿甚至内存溢出（因为java本身的垃圾回收机制是动态分配内存，调整的时候其本身会占用很多内存），NEW分配的内存，不宜太大。

　　1. 修改完成后保存，重启JMeter，即可生效。

　　三、小结

　　1. 这种修改堆大小的方法只适用一部分情况，并不是万能的，当需要模拟的线程数较大时，就需要根据具体情况采用分布式压测的方式了。

　　2. 命令行运行 jmeter 时，一定要禁用“查看结果树”、“聚合报告”等监听器，因为真的真的真的很消耗内存。

　　3. 磁盘监控工具有iostat & htop。

　　4. 网络监控工具有iftop。

　　5. 查看网络连接情况可以使用netstat -n | find /I "established" /c。