6轮Jmeter压测对比keep-alive的影响

6轮Jmeter压测对比keep-alive的影响

笔者在项目性能测试中，遇到过一次大数据量查询接口，接口响应时间以毫秒计。

测试人员使用Jmeter进行压测，最初的压测结果是这样的：

Transactions per Second

TPS非常不稳定，即使压3分钟也是上下波动，错误率为11%左右。

Average：425.5ms Max: 3212 ms Min: 208ms 平均TPS：105

失败原因：大部分为响应超时，有的请求没有收到，或调用接口失败。

测试人员和开发人员都非常郁闷，为什么多次压测都是这样波动，压到一定时间（1分多钟）必定波动。刚开始怀疑Jmeter脚本设置问题、怀疑后台程序问题、怀疑网络丢包，都无结果。后来考虑到项目接口是短连接，经过讨论和结合实验数据，定位到Jmeter和server端的keep-alive设置应该是影响最大。

第一次试验：Jmeter设置keep-alive，Server端不设置（默认无此关键字）

第二次试验：Jmeter设置keep-alive，Server端设置为Close

第三次试验：Jmeter不设置keep-alive，Server端不设置（无此字段）

第四次试验：Jmeter不设置keep-alive，Server端设置为Close

第五次试验：验证调用消息队列的后台进程速度的影响，Jmeter不设置keep-alive，Server端设置Close

后台读取消息队列进程的延时设置为每小于100ms的响应人为加100ms延时，发现还有调用接口失败，连接超时。经过几次试验设置为后面的每小于400ms的响应人为加100ms为最佳。

经过以上实验，结合平台的延时设置，得到了最佳实践。

最佳实践：服务进程时延设置每<400ms加100ms，两端都取消keep-alive，100用户并发限制200TPS

总共执行359157次，失败208次，成功率已经超过99.9%。

测试给出的配置结论：

编者注：

Keep-Alive模式：Connection: Keep-Alive，这个键值对的作用是让HTTP保持连接状态，因为HTTP协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP 协议为无连接的协议）；当使用 Keep-Alive 模式时，Keep-Alive功能使客户端到服务器端的连接持续有效。

在HTTP 1.1版本后，默认都开启Keep-Alive模式，只有加入加入 Connection: close才关闭连接，当然也可以设置Keep-Alive模式的属性，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。