性能压测一些心得总结（一）

1.压测确认

1.1系统结构、拓扑图

便于查看请求的整个路由过程，方便后期性能问题排查。

1.2用户信息

主要的使用用户，系统用户使用的高峰期，方便推算系统当前最大并发数。也可通过系统日志，来获取系统、各场景当前最大并发数

1.3待测场景

明确本次性能压测的待测场景，和各场景涉及的服务器

1.4数据量

明确各待测场景对应表的数据量，如果量不够需要预制

 

2.环境配置

2.1需要明确环境的点

服务器名称、服务器IP、操作系统、服务器类型、CPU、内存 等等，如果被压环境不是生产环境，需评估该环境与生产环境的性能比。

2.2压测机

需要确认单台压力机是否满足压测需求，如果无法支持，这时候就需要多个压力执行机来分布式的进行压测。

 

3.测试策略

3.1施压策略

本次压测采用的是瞬时加载、逐步加载、是否循环迭代、持续时长、各请求之间是否有停顿？还有本次压测工具选用。

3.2监控策略

3.2.1施压端

常用的性能指标：tps、平均响应时间、错误率、总请求数，请求断言设置

3.2.2服务端

常用的性能指标：CPU、内存、DISK I/O、Network I/O，监控过程最好可以适当拉长点，这样就可以有个压测前、中、后资源使用对比了。

3.2.3数据库

活动会话连接数、是否存在慢SQL、死锁等等。

3.3数据准备

数据准备主要指的是DB层面，即性能测试需要模拟实际的环境，包括数据量等，从DB层面来说，同一个库表，数据量不同在同样的业务模型下，其性能表现也是不同的。

预埋数据的准备，可以通过从生产备份，或者通过脚本、SQL语句来自定义准备一些可用的数据

3.4数据恢复

性能压测过程是否会额外产生数据，如果有要特别注意，在压测完成后及时删除多余的数据

 

4.用例设计

4.1场景分类

测试场景大的可以分为4种：基准场景、单场景、混合场景、稳定性场景

4.2注意事项

需要明确各项性能指标，如：并发数、加载时间、持续时间，最大CPU、内存、DISK I/O、Network I/O使用等等。

 

5.脚本编写

1. 为保证每个接口数据返回的正确性，需都配置相应的断言
2. 对应录制的脚本，需要用Transaction Controller管理（注意勾选Generate parent sample），以免聚合报告太多不好整理。
3. 聚合报告最好提取出来，统一生产结果，方便查看。
4. 可以配置常量吞吐量控制器，控制每秒发送量。

 

6.测试结果

在压测过程中，对原始的结果数据应尽量保存，因为前期准备和压测过程是非常繁琐耗时的，不要到最后因为缺少什么数据重新返工，不划算。

6.1问题记录

在压测过程中，对出现的问题和对应的解决方案详细记录，方便后续同类型问题的出现

6.2结果展示

1. 注意文档目录索引要详细，方便索引查找和定位
2. 如果有报错，附上报错信息
3. 压测执行需同步测试用例设计
4. 验收测试结论以表格的形式展现，方便明了。