转载 性能压测流程

性能压测背景：
小型电商公司，平常访问量不大，但是一旦涉及引流搞活动时，网站明显性能有问题，平常上线功能中基本上不太考虑性能，长期已久后，线上性能问题成为一个隐形问题，不知道站点流量上限在哪里，故需要组织一次全站点的压测，摸清线上tps瓶颈

网站关键数据量：
用户量：3.3百多万，日均新增：300-5000，在线活跃：1万-2万
商品总量：1.2百多万，在售中：18.7万 日均新增：15-2k多
订单总量:1.5百多万 日均：15k-18k

以下压测流程并不是一个完善成熟的流程，都是一步一步摸索过来的，整个过程遇到的问题和头疼点不少，有的没有解决就过了。。。。

压测流程
1、压测前期准备
梳理压测业务流程
根据线上log查询的接口访问量，记录访问高的接口情况和单接口访问峰值（峰值可作为压测tps目标参考值）
了解线上整个环境以及架构
2、压测计划制定（和参与人员同步）
参与人员：测试、运维、开发
测试方案 ：

压力测试——逐步加压，确定单个接口系统瓶颈（峰值），针对瓶颈优化
稳定性测试——以一定的压力下（大于日常）运行： 1*24h（待定，目的，以后网站日常流量的增加）
压测流程时间计划
3 、压测脚本设计：
单个业务接口加压
混合场景组合加压，压测时施并发比例
根据不同业务流程，整理该流程中的接口，并非所有的接口都有整理，eg：可以确定没有压力的接口，例如配置类的接口 每个流程中 接口
施压记录比例，可参考“线上log查询的接口访问量 ”，另外也会参考接口的重要性，比如创建订单接口，是核心重要接口，可能加压会大点*
5、压测环境申请和准备
应用服务器、数据库、中间件 、监控系统、压力机
注意项：
应用相服务器和线上环境一致or等比
数据库数据的量和线上一致，不能必线上少

6：压测脚本开发
哪些脚本需要参数化
测试数据准备：哪些参数化需要大批量的测试数据，并确定是用数据库已经存在的，还是要自己批量生成
哪些需要设置检查点
7、压测前试运行
确定脚本能够执行
确定脚本的数据执行后产生的数据，和线上隔离
确定执行结果在监控系统反应
8、压测执行
压测实施
逐步加压
记录每次压测结果（记录在模版中）
新的一轮压测前要确定环境资源和测试数据还原
压测监控：
监控节点：应用服务器、数据库服务器、其他中间件：redis、kafka，mongodb

监控指标：系统指标（平均响应时间、90%响应时间、tps）、服务器指标（cpu、内存、网络、io）

线上log：压测时报错接口日志、慢sql监控、redis大key（大于2m）

9、压测结果分析
压测结果分析时最难的，需要了解到的知识特别多，如果不是很懂这些，需要拉上有经验的开发、运维一起查找
运维优化：调整配置，eg：服务增加机器数，降低自动扩容门槛
开发优化：缓存、算法、线程池配置、sql语法
————————————————
版权声明：本文为CSDN博主「m0_37677636」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_37677636/article/details/122603407