一 压测目标
在开始做压测计划之前,一定要先明确压测的目标是什么,虽然最终的目标肯定都是优化系统的性能,但是不同的出发点,可能需要采取不同的方法。
一般来说,可能有以下一些目的:
1 挖掘系统瓶颈点,优化系统性能
尤其对新系统上线,缺乏性能基线数据,此时压测一般没有明确的qps/rt等指标,而是通过不断施压,不断逼近系统的极限,从而暴露问题,修复问题。
2 建立性能基线
主要是为了收集系统当前的最大性能指标,一般会根据业务特点,先确定对rt和错误率的容忍度,然后通过压测推算出能够支持的最大qps, 并发量等。
同时可以结合性能指标和监控数据,来建立合理的预警机制,设立系统水位报警项,限流阈值,弹性策略等。
量化系统能力/SLA等 (比如在竞标中引用)。
3 性能回归
对于已上线系统,或者性能需求明确的系统,可以根据线上实际的运行情况,确定系统需要支撑的qps/rt, 然后在涉及性能影响前做回归校验,确保性能满足预期。
4 系统稳定性
更侧重在一定压力的情况下,系统是否能长时间稳定持续的提供SLA保障。
一般可以考虑将压力设定到业务峰值的80%,持续施压。
5 网络/线路延迟稳定性等
在一些特殊的业务场合,对延迟的容忍度极小,比如DNS解析,CDN服务,多人实时在线游戏,高频交易等等,需要网络质量,尤其是不同线路(电信/联通/教育网/...)间的差异。
二 压测对象
明确了压测目标后 ,就是确定要压什么,来实现目标。
一般来说,压测对象可以这么分:
三 压测数据
压测过程中,一般主要关注一下数据指标:
1 starter/client
最重要的三个指标:
其他的:
2 server
主要是监控数据:
四 压测结果分析
一般是随着压力的增加(并发请求的增加)探究qps/rt/成功率三者的关系,从而找到系统的平衡点,如果能结合服务端的监控数据,就更好。
五 压测工具
1 jmeter
concurrent Thread Group
java sampler
composite chart
可以将多个chart组合到一个chart中,并且坐标系会自动伸缩,方便在一个图中展示结果。
六 性能指标推算方法
以上都是一些系统向的指标数据,其实对用户来说是不感知,或者说也是没有意义的。那什么样的数字是有意义的呢?举个例子:
举例分析:
1 基本算法
此处pv表意不清,实为后端日志统计的后端api的调用次数,如果有前端统计的一般意义上的pv(page visit),基本原理相同,可以简单换算一下,pv * x-ratio = 后端调用次数。
1. 获取现场每日asapi PV/UV的均值/峰值。
2. 取Max(PV峰值*0.8,每日PV均值)作为目标PV', PV'时段的UV值作为实际并发用户参考值N', 计算PV'/perMinute/N'作为每分钟用户操作触发api次数O'。
3. 根据以下规则换算成后端需要支持的qps:
4. 根据压测qps推算能够支持的最大用户同时使用数:
2 正向推演
如果现场环境数据表明,高峰期9:00~10:00有50人登录过系统,pv累计10000,那么根据(3.1),系统整体qps >= 11+ 才能维持当前用户量正常使用。
3 反向推演
如果家里环境压测结果表明,随机API调用qps=30, 保持上述假设,参照(4.2),即可支撑18人高峰期同时操作。
4 不严谨的地方
上述算法针对随机API按照1:1计算,实际上调用肯定是不均匀的,可以根据现场的数据统计下api的调用分布,压测是模拟相同的调用分布尽量贴近实际。
另外用户每分钟操作页面次数,和每次前端请求对应后端api的膨胀比都是预估出来的,虽然可以根据模型做近似,但是不如直接根据现场数据计算出来准确。
七 其他考量