某项目接口压测中,发现加大并发后,QPS压不上去。
压测结果如图所示:
1. QPS压不上去,猜测是链路某一环节出现了瓶颈。梳理整个压测链路:jmeter->clb->cvm。空跑一个无逻辑处理的接口,发现10台的client机器压测性能不如1台机器的性能,令人费解。怀疑是clb有问题。
2. 从clb端排查问题,采用wrk工具,host+域名的方式压测,验证了多台client机器比单台机器性能好的问题,与之前空跑的接口压测结果不一致(后续解答)
3. 通过以上操作排除了clb的嫌疑后,对比wrk和jmeter 两种压测工具,查看后端rs的监控发现jmeter新建的连接比wrk少。进 行抓包分析,发现jmeter有6s耗时等待。
4. 通过压测链路往前推,被质疑是压测工具的问题。
查看jmeter 压测集群端的资源消耗,发现没有瓶颈点,只能仔细梳理jmeter脚本。去除压测脚本里多余的jmeter组件,只留下https请求进行压测,发现QPS上升。对比了两个压测脚本发现,之前的脚本存在逐字遍历response逻辑。
修改脚本后的压测结果:
5. 回到之前空跑无逻辑处理接口,10台client机器不如1台机器性能的问题。
分析如下:一开始空跑一个无处理逻辑的接口,发现耗时在几毫秒,然而对于Jmeter这个压测引擎来说:本身有一些相对重一点的数据统计与分析的逻辑,要把每个请求的数据入库。 这也就导致了10ms以下的接口,产生大量的日志数据入库出现积压。(jmeter 会统计每个请求的response里的逻辑,且放到Influxdb中)
目前采用k8s+jmeter的压测方案,10台slave机器的数据汇总到1台master,汇总的数据量很大,所以会出现qps出现下降的情况。
在本次分析问题的过程中,依旧采用控制变量法来排查问题,最终定位问题到jmeter端。项目的接口返回的报文有上万个字符,逐个进行遍历解析,jmeter的资源被占用掉无法迅速的去处理请求,值得关注的是grafana统计的耗时其实是从jmeter发送请求到接收请求报文的这个时间,不包含jmeter自身操作的耗时,如返回值解析等操作。
在以后的压测中,要规范jmeter脚本的书写,避免‘埋坑’。
在本次的实践过程中,还发现了jmeter自身的问题,对于10ms以下的请求周期会出现瓶颈。
对于排查链路问题,空跑无逻辑处理接口也是一个很不错的选择呦~
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。