【项目实战-3】脚本存在遍历解析耗时操作，QPS压不上去

【问题表现】

某项目接口压测中，发现加大并发后，QPS压不上去。

压测结果如图所示：

【问题分析与排查思路】

1.   QPS压不上去，猜测是链路某一环节出现了瓶颈。梳理整个压测链路：jmeter->clb->cvm。空跑一个无逻辑处理的接口，发现10台的client机器压测性能不如1台机器的性能，令人费解。怀疑是clb有问题。

• 场景一：单台client--clb---40台rs--500并发： 2w qps：(压测工具jmeter)
• 场景二：10台client--clb--40台rs--5000并发： 1.2wqps：(压测工具jmeter)

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以下的请求周期会出现瓶颈。

对于排查链路问题，空跑无逻辑处理接口也是一个很不错的选择呦～