一次简单的性能测试记录
性能测试
1.性能测试的场景:
对性能压测接口:抢购进行测试
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092447838-63285418.png)
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448360-1012996799.png)
过程:
刚开始没有提供接口,自己去页面抓包然后通过登录接口获取token才能去验证"藏品详情""藏品列表"接口,
遇到问题:
- 抢购接口,需要实名认证。目前登录用户都是excel中的手机号,验证码为111111。
- 抢购后还要支付,没法批量支付(这个后续通过0元商品,解决)
经过客户更改开放接口:抢购,直接输入手机号,不用token值信息,就可以调:购买检查-写表插库-上链 动作。
先压藏品详情和藏品列表接口
这两个接口有用到本地缓存,所以查询的效率会很高:
两台机器分别压500并发10次 5000*2台 ,没有错误, 总时长1:52 tps90个
所以详情的接口还好
开始压抢购的接口:
抢购的接口 50个就报错了
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448024-1820908485.png)
现象是:1s启动50个线程,会大量的报错,tps刚上升一下,然后就卡在1左右不动了,像是限流一样1s一个请求。
开发定位日志,找到原因:死锁问题,评估这是造成今天资源迅速被消耗的主要原因
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448437-1352577273.png)
经过修复后:表现
50个不同用户,同时请求交易接口,请求一次
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092447903-1683302671.png)
调整压测策略:50并发,每3秒发一笔,发20次,一共1000笔交易
tps:9.7
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448007-1843579647.png)
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448218-703838335.png)
并发200,每个10次 总量2000次
tps:11.5 35个失败的
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092447958-397807643.png)
第二天:
开会复盘压测结果,tps还是太小了,讨论技术优化方案:
- 从业务上拦截掉部分订单进入:随机的给用户返回 售罄的结果,用户二次点击进来可以购买。
- 从代码逻辑来优化:1.将上链的动作异步化。2.采用消息队列的结,对峰值的压力进行削弱,未进入队列的用户先返回失败,再次进入的时候,重新排队。
- 运维查看到很多慢sql,select count(*) ,需处理。
下午压测逻辑:
用两台压力机去压测,同时点击,上并发线程
测试刚开始1s能启动多少线程:
测试效果还是看事务的响应时间,tps10的话 即使调成1s启动50个线程,运行显示还是5s钟才跑结束。
拆分压测 将一个接口拆三个部分,查询校验-写表-上链逻辑
- 注释上链动作
并发200,每个10次, 昨晚是时长2:53 现在是1:11 但是失败量昨晚是35,现在是400个(后来反馈说是加了单用户禁止重复请求逻辑。)
tps:28.1
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448052-265552649.png)
此时的内存和cpu都是满的
- 单独测只生成订单,把订单检查去掉
这次两台机器分别压300并发10次 3000*2台 没有错误率 时长单台3:27
Tps 28.9
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092448169-97071944.png)
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092447967-2018706376.png)
- 把写表的代码注释吗 只测订单检查的代码
还是两台机器分别压300并发10次 3000*2台 ,没有错误率 时长单台2:14 tps44个
结论:上链会影响tps。上链后是12个,不上链是28个
开发加入队列机制:
线程数开200个 超过200的线程不让进入,这样可以减少每轮请求的完成时间,如:之前2000个请求 要3分钟结束,没有失败的,但是现在只要1分钟结束,有50%失败的
调整队列长度200。
试了300 请求都成功了,且处理时长没有减少,有个请求还是17s,逻辑不对
调整队列长度20。生效了
有大量异常,响应时间也缩短到6s
![](https://img2023.cnblogs.com/blog/1773218/202303/1773218-20230320092447895-1598212568.png)
后来经排查,是线程数的影响:虽然队列是200,但是线程数150
将队列设成140,用户数150就会有报错了,生效
队列设成151,用户数150不会有报错,不会报错,失效
生产时候线程数可以配置到600,所以队列只要小于线程数就会生效
队列消费后,可以有新的队列进入消费,组建机制保证。
本文来自博客园,作者:Joson6350,转载请注明原文链接:https://www.cnblogs.com/josonhuang/p/17075800.html