一、性能测试关键点
- 评估性能指标——线程tps(可架构给)
吞吐量qps(可架构给)
错误率(可架构给)
平均响应时间(可架构给) - 模拟线上数据量
- 了解接口有没有缓存,有缓存的需要设计
每次调接口获取的是不一样的数据
二、如何评估需要测试的接口线程数?
- 针对老项目:
- 系统里查看过去一周(或者一个月)内,接口调用量最高的那一天,然后
再找到当天中接口调用量最高的时间点(分钟级别),比如说是在12:10调
用量为10000,那么我们再换算每秒调用量10000/60=166,因此可以确定
这个接口tps只要达到166即可满足
- 系统里查看过去一周(或者一个月)内,接口调用量最高的那一天,然后
- 针对新项目:
- 二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数(冗余系数一般
为2-5之间,一般可取3)如金融股票交易app,一般是早上9点到下午3点,
76060=25200秒,注册用户1000万,日活差不多100w,80%=80w,
80w/25200*3=95.接口吞吐量是95即可满足
- 二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数(冗余系数一般
三、压测实际操作
当确定吞吐量指标,根据指标去压对应的接口:
1、压测设置参数:添加线程组,线程数=用户数/10;ramp-up period多少秒内启动所有线程,默认一般是1秒,0就是立即全部启动;循环次数一般写永远,压测个10-30分钟,看报告
2、聚合报告:Samples发出的请求数、Average单个Request的平均响应时间(ms)、error错误率、Throughput简称tps,吞吐量,每秒处理的请求数。
3、写接口,如果多个接口添加正则表达式,上下接口串联
4、关联数据库,cmd运行: jmeter logFile -o reportPath得到报告
性能测试指标对应压测方法:
吞吐量的预估值=考虑用什么方法去进行压测
- 500以下 JM 注:接口吞吐指标在500以下,JM就能满足
- 500-5000 JM分布式或者LR
- 5000以上 中控+多机部署
- JM分布式:JM上配置参数接口,jenkins配置多台服务器,一台控制机,多台负载机,控制机的密钥加到负载机中;
- JM+Grafana+Influxdb监控性能参数,内存,cpu占用情况,接口吞吐量
- Linux系统
- 内存
- 换页swap空间
free -m | sed -n '2p' | awk '{print "used mem is "$3"M,total mem is "$2"M,
used percent is "$3/$2*100"%"}'
四、接口的性能瓶颈怎么查看?
随着tps越来越高,如何评估接口性能qps指标:
- 软硬件的资源利用情况会越来越高,直到满负载(内存,cpu占用情况)
- 吞吐量会不断变高,直到达到峰值,下降或企稳
- 响应时间会慢慢变高,超过吞吐量峰值,响应时间曲线会急剧拉升(因
硬件资源满负载,软件接口无法处理超+ 高并发,接口处理速度最后会急剧变慢)
所以:性能指标是吞吐量最高的那个值,响应时间缓慢拉升到急剧拉升的拐点,硬件
资源最大,这三者的坐标区域中间,就是性能峰值
五、怎么做性能优化?
1、最简单的加线程,进程
2、数据库层面,加索引,加缓存,一些机算上的结果缓存,
表数据太多,分表,sql优化
3、在有IO(网络IO,磁盘IO)的时候,批量读,写,合并
网络请求,减少与单点的交互
4、代码更高效的实现,改运算逻辑,如本来以账户维度计
算金额,改成以产品维度去计算
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取