性能测试场景概念解释
性能测试场景概念解释
性能测试的概念
性能测试场景设计基本概念
- 场景设计——单业务性能测试场景
- 场景设计——混合业务性能测试场景
- 场景设计——稳定性性能测试场景
- 场景设计——异常性能测试场景
- 场景执行——单业务性能测试场景
- 场景执行——混合业务性能测试场景
- 场景执行——稳定性性能测试场景
- 场景执行——异常性能测试场景
性能测试的概念
性能测试是针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件下执行性能场景，分享判断性能瓶颈并调优，最终得出性能结果，来评估系统的性能指标是否满足既定值。
性能项目的分类
- 新系统性能测试类：这样的系统一般都会要求测试出系统的最大容量
- 旧系统的新版本的性能测试类：这样的项目一般都和旧版本对比，只要性能不下降，就可以根据历史数据推算容量，这样的UI调优要求一般都不大
- 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还有调优到最好的需求。
性能团队的职责定位
- 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上如此
- 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
- 性能测试+分析调优：针对给定的系统，做全面的性能测试，同事将系统调优到最优状态。
性能场景分类
性能场景设计的逻辑
- 测试
- 调优
- 推算
性能测试分类
单业务性能测试场景：单业务的容量场景，测出最大TPS
混合业务性能测试场景：递增场景，最大TPS，最快响应时间场景
稳定性性能测试场景：长时间运行，及最大业务量是多少
异常性能测试场景：异常性能测试前提是有压力，压力之下模拟异常
场景及作用
- 单业务性能测试场景：每个业务都压到最大TPS，为后续场景做数据对比
- 混合业务性能测试场景：混合容量性能场景，所有业务根据比例加到一个场景中，在数据，硬件环境，监控等配合之下分析瓶颈并调优
- 稳定性能测试场景：长时间运行，观察系统的性能表现，分析瓶颈并优化的过程
- 异常性能测试场景：异常的定义很重要，之前常用的手段是宕主机，宕应用，宕网卡。云基础框架中还可以宕容器，宕虚拟机，宕缓存，宕队列，宕集装箱，宕流控，宕熔断等等。实际场景中根据系统中的业务框架和部署架构分析来决定模拟什么样的异常。
性能指标
- RT：Response Time,响应时间，包括request time和response time
- HPS：Hits Per Second,每秒点击数
- TPS：Transactions Per Second,每秒事务数
- RPS：Requests Per Second,每秒请求书
- QPS：Queries Per Second,在MySQL中指每秒SQL数
- CPS：Cods Per Second,在HTTP协议中偶尔有提到。指的是http返回码每秒
- PV：Page View,页面浏览量
- UV：Unique Visitor,独立访问者
- IP：internet Protocol,本指IP地址，在性能钟指独立IP数
- Throughput：吞吐量
- IOPS：Input/Output/Operations Per Second,通常描述磁盘
性能指标的划分
- 场景指标
- 时间指标
- 容量指标
- 资源利用率指标
从生产环境的数据到性能场景
取出生产环境的数据并统计：
- 从生产环境取出数据，可取出秒、分、时、天、月、年的数据，做成图，比如取出2021年6月30日到2021年7月5日的数据。以天为单位展示图。
-
再从图上取出业务量相对高的一天，查看1天内的业务趋势，用以分钟为单位的图，或者以小时为单位的图查看趋势
-
根据图设计如下业务模型：
- 普通日的比例场景，可以覆盖大部分的业务时间
- 以天为单位计算每天的总业务量比例
- 取出其中的平均值
- 删除0%的业务场景
- 业务A峰值的场景，这个场景可以覆盖某特定业务A的峰值：
- 有了第一个场景之后，还需要分析更细化的业务场景，也就是业务占比比较高的业务场景
- 比如以小时或者秒为单位的图中看到的某个时间点（业务A峰值时间点）的业务场景
- 业务B峰值的场景，这个场景可以覆盖某特定业务B的峰值：
- 从前边的图中可以看到，从几点到几点的时候，业务B较多，因为这个时间点业务量大，所以使用这个时间点的业务比例，统计出这个时间点的业务比例。
- 普通日的比例场景，可以覆盖大部分的业务时间
要做的场景
| 序号 | 场景分类 | 业务 |
|---|---|---|
| 1 | 单业务场景 | 登录 |
| 2 | 单业务场景 | 售票 |
| 3 | 单业务场景 | 查询 |
| 4 | 单业务场景 | 退出 |
| 5 | 混合业务容量场景 | 普通日比例场景 |
| 6 | 混合业务容量场景 | 售票业务峰值的场景 |
| 7 | 混合业务容量场景 | 查询业务峰值的场景 |
| 8 | 稳定性场景 | 普通日比例场景 |
| 9 | 稳定性场景 | 售票业务峰值场景 |
| 10 | 异常场景 | 普通日比例场景：操作A、操作B、操作C |
| 11 | 异常场景 | 售票业务峰值场景：操作A、操作B、操作C |
响应时间-线程数-用户数-TPS
TPS=在线用户数*并发度
并发线程= TPS*响应时间
28原则和258原则合理吗？
28原则：一天8小时运行，20%为高峰区域
258原则：2秒响应时间可以接受，5秒用户感知较慢，8秒用户感知很差
- 高峰区及响应时间应该根据实际数据分析或者实际业务来规定，不是死的。
