记一次并发压测业务场景的数据提取传参准备问题在这里插入代码片
压测对象数据库:国产达梦数据库
压测工具:jmeter
大致脚本:
登陆接口(获取token、用户信息)
查询接口(获取后续压测接口所需要的主要业务数据,获取返回数据后通过json提取器来提取所需对象参数)
压测接口
登出接口
问题:
该用户需要通过前置的查询接口返回数据中获取响应的参数对象(pay_cert_id,pay_app_id等),一开始选择使用最简单最常用的json提取器来提取该参数 ,
测试完成后开始压测,发现不满足业务场景要求:每条数据在第一次通过该接口进行处理的时候会进行查询和插入的操作,而同一数据再次请求该接口时仅会进行少量的查询操作。为保证压测的有效性,需要对参数的提取进行随机的选择,但是返回数据的结构为data.list[0].pay_cert_id,通过直接修改match.no的方式无法获取到随机的pay_cert_id。于是直接换成正则表达式提取器,可以直接取出返回数据中所有的pay_cert_id,
并且通过修改匹配数字为‘0’来随机获取对应的pay_cert_id,经测试,可以随机获取数据。
调试完成后进行压测,发现压测结果远远偏离预期设想的结果,还是存在数据重复提取的问题。经过检查发现:
1、该查询接口返回数据中,仅存在二十条数据,从二十条数据中去随机提取一条数据的pay_cert_id,在并发压测中一定会出现提取同样数据的问题,因此不能选择用随机提取的方法,
2、每个查询接口返回数据中的二十条数据与一千并发压测的样本数差距太大,
所以,解决方式为通过修改分页参数(pagesize)的方法使接口每次返回数据100条,并且为线程组添加计数器,
然后修改正则表达式提取其中的匹配数字为‘${num}’来进行顺序的提取。
修改完成后,进行压测。然后压测大约30s之后。。。。。。。。。。。。闪退,排查下来是因为返回数据太多(每s接收数据80mb以上),jmeter的内存不够用了。
实在无奈:最后还是去数据库里把准备好的压测数据全部查出来,然后将数据中对应的参数查询结果导出成txt文件,通过jmeter的csv文件读取来获取参数。
最后,本次csv文件读取的txt文件中含有10w条数据,但是这个txt的大小很显然也会对jmeter并发压测时的可分配内存产生影响,太大的话极有可能闪退,但是具体极限是多少还不确定,只能慢慢探索了。