/ QA

业务压测设计的心得

很久没更新博客了,原因是……本地有notebook整理资料,processon云工作文档,还有本地导图,各种文档,说实话维护不过来了,应该有一种方式,无感知的积累知识、心得、工作,而不是博客这样刻意去发布。说说正题压测吧  

压测方案:如果你没做过压测,可能想的是jmeter、代码脚本开发、各种日志数据排查、压力点分析、统计报告等等……这些都是执行的事,实际上更多还是对业务、服务的调研,结合测试技术、开发技术,综合考虑的一个能发现性能问题的低成本的可执行方案。

压测业务链:一般是从某种业务场景开始,分析业务走向,确定链路。确定业务走向后,就可以确定涉及哪些服务,调用方式,数据处理,持久化,数据库事务等等,基本就确定了压测要观察的对象。

压测入口:一个业务链的节点很多,可以从业务入口切入施压,也可以从中间。大部分都会模拟业务入口去施压,一个是更贴近真实的业务场景,再一个暴露的问题更全面,当然对开发配合和效率也要求更多,问题越多,对分析能力,解决效率自然要求就高了。施压入口提前,也便于测试模拟执行,有很多执行方式可选。

压测压力:一般都说多少并发量,比如1000并发量,那么问题来了,是每秒1000次,还是每毫秒1000次,还是微妙……再一个是平均分布,还是一秒的第一刻或最后一刻爆发1000次,之后的一秒间空闲。或者是模拟1000个用户,定义请求频率和持续时间。总之你得弄明白你要施压的模拟压力应该是什么,正常来说TPS或QPS来描述压力是相对统一的概念。

压测实施:这里头就各式各样都有了,终归是能有效解决问题就行,不拘泥于高深浅显技术。是人工执行,工具执行,还是自己开发代码执行,或者统计生产的用户高峰数据,都是一种手段,只要是符合你设计的压测方案,模拟压力符合,而且成本可接受,都是可以的。

压测报告: 出性能曲线,找出拐点,给出优化后的QPS,找到或解决了哪些压力点