性能压测一些心得总结(一)

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. 验收测试结论以表格的形式展现,方便明了。
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值