标签：200 记录 队列 性能 接口 压测 线程 测试 tps
性能测试
1.性能测试的场景：
对性能压测接口：抢购进行测试
过程：
刚开始没有提供接口，自己去页面抓包然后通过登录接口获取token才能去验证"藏品详情""藏品列表"接口，
遇到问题：
- 抢购接口，需要实名认证。目前登录用户都是excel中的手机号，验证码为111111。
- 抢购后还要支付，没法批量支付(这个后续通过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.采用消息队列的结，对峰值的压力进行削弱，未进入队列的用户先返回失败，再次进入的时候，重新排队。
- 运维查看到很多慢sql，select count(*) ，需处理。
下午压测逻辑：
用两台压力机去压测，同时点击，上并发线程
测试刚开始1s能启动多少线程：
测试效果还是看事务的响应时间，tps10的话 即使调成1s启动50个线程，运行显示还是5s钟才跑结束。
拆分压测 将一个接口拆三个部分，查询校验-写表-上链逻辑
- 注释上链动作
并发200，每个10次， 昨晚是时长2:53 现在是1:11 但是失败量昨晚是35，现在是400个(后来反馈说是加了单用户禁止重复请求逻辑。)
tps：28.1
此时的内存和cpu都是满的
- 单独测只生成订单，把订单检查去掉
这次两台机器分别压300并发10次 3000*2台 没有错误率 时长单台3:27
Tps 28.9
- 把写表的代码注释吗 只测订单检查的代码
还是两台机器分别压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，所以队列只要小于线程数就会生效
队列消费后，可以有新的队列进入消费，组建机制保证。
标签：200,
记录,
队列,
性能,
接口,
压测,
线程,
测试,
tps
From： https://www.cnblogs.com/josonhuang/p/17075800.html