性能测试学习笔记(1)
确认性能需求
- 估算吞吐量/响应时间
- 有监控就check监控中接口的吞吐峰值(TPS/QPS)和响应时间峰值
- 没有监控,线上没有流量
a. 可以先预定一个响应时间(可接受的底线值),然后开始做压测,观察在这个响应时间之内的最大吞吐量。
举个栗子:
服务:
获取配送人员的当前地理位置
线上场景:
X包配送人员1W
Y队配送人员2W
同时在线最多人数 8k
响应时间(要求):
10ms
推算吞吐(通过压测):
线性增加压力,观察响应时间,当加到一定压力时,响应时间达到要求,记录压力值b. 根据线上的业务需求来推算性能指标
举个栗子:
服务:
配送人员地理位置上传服务
线上场景:
X包配送人员1W
Y队配送人员2W
同时在线最多人数 8k
推算吞吐:
8k/s
响应时间:
根据推算吞吐去做压测(主要观察90线和95线,平均值和中位数做参考),获取响应时间
压测过程中的关注点
测试前的关注点:
- 确定好性能需求
- 确定好压测时间(县上压测,为了降低影响,就选流量最小的时间点)
- 确定好压测工具,压测脚本(输入尽可能与线上一致)
- 确定是否要压到拐点?
测试过程中关注点:
- 吞吐是否压得上去?
- 是否有业务错误?(超时,上传位置太快等业务错误)
- 响应时间是否满足要求?
- 服务器性能指标是否正常?(htop命令监控)
- DB,Readis的运行状况是否良好?
- 是否有必要压到拐点
测试结束后关注点:
- 压测的输入输出是否无误差,无缓存等其他因素影响(输入数据尽可能的与线上情况一样!一样!一样!)
- 压测结果是否满足性能需求?
- 压测产生的垃圾数据记得清理
性能测试,做不难,难在分析!难在分析!难在分析!
- 为什么加了压力,系统吞吐上不去?
- 为什么加到一定压力,DB或者redis发生抖动?
- 为什么加到一定压力,系统吞吐变慢?响应时间变大?是因为已经超负荷还是系统性能太差?
... ...