一次简单的性能测试记录

 

性能测试

1.性能测试的场景：

对性能压测接口：抢购进行测试

 

过程：

刚开始没有提供接口，自己去页面抓包然后通过登录接口获取token才能去验证"藏品详情""藏品列表"接口，

遇到问题：

1. 抢购接口，需要实名认证。目前登录用户都是excel中的手机号，验证码为111111。
2. 抢购后还要支付，没法批量支付(这个后续通过0元商品，解决)

经过客户更改开放接口：抢购，直接输入手机号，不用token值信息，就可以调：购买检查-写表插库-上链 动作。

 

先压藏品详情和藏品列表接口

这两个接口有用到本地缓存，所以查询的效率会很高：

两台机器分别压500并发10次 5000*2台 ，没有错误， 总时长1:52 tps90个

所以详情的接口还好

开始压抢购的接口：

抢购的接口 50个就报错了

现象是：1s启动50个线程，会大量的报错，tps刚上升一下，然后就卡在1左右不动了，像是限流一样1s一个请求。

开发定位日志，找到原因：死锁问题，评估这是造成今天资源迅速被消耗的主要原因

 

经过修复后：表现

50个不同用户，同时请求交易接口，请求一次

 

调整压测策略：50并发，每3秒发一笔，发20次，一共1000笔交易

tps：9.7

并发200，每个10次 总量2000次

tps：11.5 35个失败的

 

第二天：

开会复盘压测结果，tps还是太小了，讨论技术优化方案：

1. 从业务上拦截掉部分订单进入：随机的给用户返回 售罄的结果，用户二次点击进来可以购买。
2. 从代码逻辑来优化：1.将上链的动作异步化。2.采用消息队列的结，对峰值的压力进行削弱，未进入队列的用户先返回失败，再次进入的时候，重新排队。
3. 运维查看到很多慢sql，select count(*) ，需处理。

 

下午压测逻辑：

用两台压力机去压测，同时点击，上并发线程

测试刚开始1s能启动多少线程：

测试效果还是看事务的响应时间，tps10的话 即使调成1s启动50个线程，运行显示还是5s钟才跑结束。

拆分压测 将一个接口拆三个部分，查询校验-写表-上链逻辑

1. 注释上链动作

并发200，每个10次， 昨晚是时长2:53 现在是1:11 但是失败量昨晚是35，现在是400个(后来反馈说是加了单用户禁止重复请求逻辑。)

tps：28.1

此时的内存和cpu都是满的

2. 单独测只生成订单，把订单检查去掉

这次两台机器分别压300并发10次 3000*2台 没有错误率 时长单台3:27

Tps 28.9

 

3. 把写表的代码注释吗 只测订单检查的代码

还是两台机器分别压300并发10次 3000*2台 ，没有错误率 时长单台2:14 tps44个

 

结论：上链会影响tps。上链后是12个，不上链是28个

 

开发加入队列机制：

线程数开200个 超过200的线程不让进入，这样可以减少每轮请求的完成时间，如：之前2000个请求 要3分钟结束，没有失败的，但是现在只要1分钟结束，有50%失败的

 

调整队列长度200。

试了300 请求都成功了，且处理时长没有减少，有个请求还是17s，逻辑不对

调整队列长度20。生效了

有大量异常，响应时间也缩短到6s

后来经排查，是线程数的影响：虽然队列是200，但是线程数150

将队列设成140，用户数150就会有报错了，生效

队列设成151，用户数150不会有报错，不会报错，失效

生产时候线程数可以配置到600，所以队列只要小于线程数就会生效

队列消费后，可以有新的队列进入消费，组建机制保证。