Jmeter的吞吐量很低

8月 18, 2015 |

最近在玩Jmeter的时候发现测试的吞吐量一直很低,开始一直怀疑是tomcat配置问题,弄了一大半天才发现,使用GUI压力测试时,JMeter一直在GC,改成非GUI模式吞吐量就上去了,由于服务器和JMeter运行在同一个机子上,测试的吞吐量大概在500-1200/s。但是当执行的次数比较多的时候,后面失败的次数越来越多。
jmeter-n.cmd 是windows平台的非GUI的测试入口,跟上.JMX的测试用例配置文件就OK了。

jmeter-n.cmd ../my_test_case/test.jmx

以下是测试结果输出:

Creating summariser <summary>
Created the tree successfully using test.jmx
Starting the test @ Wed Aug 19 13:54:25 CST 2015 (1439963665073)
Waiting for possible shutdown message on port 4445
summary +6660 in 5s = 1363.1/s Avg: 17 Min: 1 Max:1627 Err: 0 (0.00%) Active: 75 Started: 200 Finished: 125
summary +3340 in 5s =? 719.4/s Avg:? 89 Min: 1 Max: 992 Err:? 0 (0.00%) Active: 0 Started: 200 Finished: 200
summary = 10000 in 10s = 1049.3/s Avg:??? 41 Min:???? 1 Max:? 1627 Err:???? 0 (0.00%)
Tidying up ...??? @ Wed Aug 19 13:54:34 CST 2015 (1439963674644)
... end of run

2023.4.13更新

在jmeter所在的linux上,修改如下配置
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
能降低CPU的使用且显著提高吞吐量,tps从开始的1w 上升到1.6w(tomcat server配置:2cpu , 2GB , jmeter: 4cpu, 4GB, 内网连接)

处于ESTABLISHED状态的连接

A -----FIN-----> B
FIN_WAIT_1       CLOSE_WAIT
A <----ACK------ B
FIN_WAIT_2
(B can send more data here, this is half-close state)
A <----FIN------ B
TIME_WAIT        LAST_ACK
A -----ACK-----> B
|                CLOSED
2MSL Timer
|
CLOSED

也就是说只有主动发起连接的一方才会进入TIME_WAIT,
RFC 1323 添加的时间戳字段让客户端使用TIME_WAIT状态的端口, 服务器端使用 LAST-ACK变成可能。
当tcp缓存中的数据过多时,tcp会减少广播给peer的窗口大小,直到win=0从而不确认客户端数据,让其重传, 这会有两个影响,1 发送的数据包增多了。2,重传次数增多了。

TIME_WAIT和CLOSE_WAIT

tomcat 通过server.tomcat.connection-timeout 配置项控制一个空闲的连接多久后主动关闭, 默认是60s,如果tomcat主动发起关闭, 那么客户端会进入CLOSE_WAIT(对方调用close而本方未调用close), 发送FIN后进入LAST_ACK

本地的TIME_WAIT的套接字可以重用, CLOSE_WAIT的套接字肯定是没有调用关闭导致的

NIO API 的SelectionKey.cancel()不会触发Channel.close, 需要主动调用Channel.close 来关闭本端的连接。

参考:
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

Posted in: JMeter

Comments are closed.