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

时间:2022-07-28
本文章向大家介绍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

第四方案(最差)

客户端keep-alive,服务器端不设置,是最不稳定的。TPS周期性波动。

第三方案

客户端keep-alive,服务器端设置关闭,稳定度排第三。波动比较早。

第二方案

客户端取消keep-alive,服务器端也不设置,比较稳定,TPS平稳。

第一方案(最佳)

客户端取消keep-alive,服务器端设置关闭,最稳定,TPS平稳。

编者注:

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次请求就断开。