目录:
性能分析思路
- 总体思路
- 瓶颈的精准判断
- 线程递增的策略
- 性能衰减的过程
- 响应时间的拆分
- 构建分析决策树
- 场景的比对
- 瓶颈的精准判断
- TPS曲线
- 假设线程是等比例递增的,对于上面那个图,我们可以看到在第二阶梯已经出现性能瓶颈了,因为理论来说第二阶梯的TPS应该是第一阶梯的两倍,然而实际并不是,所以出现了性能瓶颈
- TPS的意义(从TPS曲线得到的信息)
- 有没有瓶颈:其实准确说所有的系统都有性能瓶颈,只看我们在哪个量级在做性能测试 了。
- 瓶颈和压力有没有关系:TPS 随着压力的变化而变化,那就是有关系。不管压力增不增 加,TPS 都会出现曲线趋势问题,那就是无关。
- 响应时间曲线
- TPS曲线和响应时间曲线的着重点
- 响应时间是用来判断业务有多快的,而 TPS 才是用来判断容量有多大的。
- TPS曲线和响应时间曲线的着重点
- TPS曲线
- 线程递增的策略
- 两种线程递增场景(海量免费学习资料,软件测试交流:1140267353,还会有同行一起技术交流)
- 总结
- 对一个系统来说,如果仅在改变压力策略(其他的 条件比如环境、数据、软硬件配置等都不变)的情况下,系统的最大 TPS 上限是固定的。
- 关于秒杀场景的测试,前期一定要做好预热,预热指的是有一定的流量在跑,然后在突增压力,这样的比较类似于实际场景;而不是直接一次就大流量进入系统。
- 性能衰减的过程
- 只要每线程每秒的 TPS 开始变少,就意味着性能瓶颈已经出现了。 但是瓶颈出现之后,并不是说服务器的处理能力(这里我们用 TPS 来描述)会下降,应该 说 TPS 仍然会上升,在性能不断衰减的过程中,TPS 就会达到上限。
- 响应时间的拆分
- 构建分析决策树
- 它是对架构的梳理,是对系统的梳理,是对问题的梳理,是对查找证据链过程的梳理,是对分析思 路的梳理。它起的是纵观全局,高屋建瓴的指导作用。
- 场景的比对
- 当你觉得系统中哪个环节不行的时候, 又没能力分析它,你可以直接做该环节的增加。
参数化数据
- 参数化逻辑
- 分析业务场景
- 罗列出需要参数化的数据及相对应的关系
- 将参数化数据从数据库中取出或设计对应的生成规则
- 合理地将参数化数据保存在不同的文件中
- 在压力工具中设置相应的参数组合关系,以便实现模拟真实场景
性能场景:做参数化之前需要考虑的内容
- 需要关注的数据
- 参数化数据、监控数据和基础铺底数据
参数化数据
- 参数化数据可能出现的情况
- 数据不均衡
- 参数化数据量不足
参数化数据的疑问
-
参数化数据应该用多少数据量?
-
参数化数据从哪里来?
- 参数化数据主要分为两类
- 用户输入的数据在后台数据库中已存在,比如我们上面示例中的用户数据。
- 数据特点:存在后台数据库中;需要用户主动输入;用户输入的数据会和后台数据库中的数据做比对。
- 这类数据必须查询数据库之后再参数化到工具中。
- 用户输入的数据在后台数据库中不存在。在业务流中,这些数据会 Insert 或 Update 到数 据库中。
- 数据特点:数据库中原本不存在这些数据;在脚本执行成功后会将这些数据 insert 或 update 到数据库中;每个用户输入的数据可能相同,也可能不同,这取决于业务特点。
- 这类数据必须通过压力工具做参数化,同时也必须满足业务规则。
- 数据满足条件:要满足生产环境中数据的分布;要满足性能场景中数据量的要求。
- 用户输入的数据在后台数据库中已存在,比如我们上面示例中的用户数据。
- 参数化数据主要分为两类
-
参数多与少的选择对系统压力有什么影响?
- 参数取得过多,对系统的压力就会大;参数取得过少,不符合真实场景中的数据量,则无法 测试出系统真实的压力。
-
参数化数据在数据库中的直方图是否均衡?
- 指的是每个用户的数据分布是否符合业务场景;比如同样是下单业务,给用户A造了几十万数据,给用户B造了几条数据,明显就是不合理的
性能场景设计
前期工作(海量免费学习资料,软件测试交流:1140267353,还会有同行一起技术交流)
- 确认需要压测的业务,以及这些业务对应的业务比例(可以从日志中获取)
- 确定业务目标TPS
- 确定业务目标响应时间
基准性能场景
- 目的
- 为了测试出单业务的最大容量,以便在混合容量场景 中判断哪个业务对整体容量最有影响。
容量性能场景
- 要点
- 场景不断
- 控制比例
- 容量TPS计算方法
- 将各业务的TPS累加即可
稳定性性能场景
- 要点
- 稳定性一般强调的是系统稳定跑一段时间,如要求2000w业务量在线上安全跑一周
- 最小测试时长 = 2000w / 容量TPS(这个值看容量性能场景的计算方式)
异常性能场景
- 测试方法
- 总的来说就是让各种服务处于不稳定;比如主redis宕机,看redis切换时会不会导致功能问题
性能监控设计
监控设计步骤
- 分析系统的架构;针对各个组件进行监控
- 监控要有层次,要有步骤;先全局,后定向定量分析
- 通过分析全局、定向、分层的监控数据做分析,再根据分析的结果决定下一步要收集 什么信息,然后找到完整的证据链
全局监控设计
os层
- 关注参数:CPU、I/O、Memory、Network、System、Swap
CPU参数 | 参数含义 |
---|---|
idle | CPU 空闲状态的时间百分比 |
iowait | I/O 等待所占 CPU 时间百分比 |
irp | 中断 |
nice | 运行正常进程消耗的 CPU 时间百分比 |
softirp | 软中断 |
steal | |
system | 系统进程消耗的 CPU 时间百分比 |
user | 用户进程消耗的 CPU 时间百分比 |
CPU队列 |
IO/Disk参数 | 参数含义 |
---|---|
TPS | 每秒钟物理设备的 I/O 传输总量 |
rrqm/s | 每秒进行 merge 的读操作数目 |
wrqm/s | 每秒进行 merge 的写操作数目 |
r/s | 每秒完成的读 I/O 设备次数 |
w/s | 每秒完成的写 I/O 设备次数 |
bi | 由块设备读入数据的总量,即读磁盘 |
bo | 写到块设备数据的总量,即写磁盘 |
r_await | 表示读取的平均响应时间 |
w_await | 写入的平均响应时间 |
Memory参数 | 参数含义 |
---|---|
total | 总计物理内存的大小 |
free | 可用内存(要看available) |
used | 已用内存 |
Buff/cache | 缓冲区内存总量 |
available | 真正可用的内存 |
Network参数 | 参数含义 |
---|---|
TX:发送流量 | |
RX:接收流量 | |
Send-Q/Recv-Q | 发送队列、接收队列 |
全连接队列 | |
半连接队列 |
System参数 | 参数含义 |
---|---|
interrupt | 表示某一时间间隔内观测到的每秒设备中断数 |
Context switch | 每秒产生的上下文切换次数 |
Swap | 参数含义 |
---|---|
total | 交换区总量 |
free | |
used | |
si | 内存进入内存交换区的内存大小 |
so | 内存交换区进入内存的内存大小 |
DB层
操作系统常用计数器
- 命令模块
- CPU参数含义
us CPU
是用户态进程消耗的 CPU 百分比wa cpu
是 I/O 读写等待消耗的 CPU 百分比。sy CPU
是内核消耗的 CPU 百分比si CPU
是软中断消耗的 CPU 百分比
看到这里,非常感谢您的耐心,如果您觉得有收获,记得给小枫点赞关注哟!!!