标签：总结 定位 场景 性能 TPS 测试 参数 数据 CPU

一、理论

1.1概念

• 性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

1.2性能指标

• 指标包括：时间指标、容量指标和资源利用率指标
  • 时间指标指的是接口响应时间、业务响应时间
  • 容量指标指的是接口容量、业务容量
  • 资源利用率指标指的是操作系统（CPU、IO、Mem、Disk、Network、System）、JVM等
• 指标的由来：可以是根据业务场景，同团队成员商讨获得；或者实际执行压测时没有设置指标，目的设置为查看系统的性能瓶颈

1.3模型

• 模型指的是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子
• 通俗的可以理解为，模型可以让测试人员知道具体业务的并发情况，方便测试人员根据模型设计具体的压力比例
• 模型数据的获得：一般是从生产环境中统计得到（比如对各个节点打log,然后根据log来分析得到流量情况）

1.4性能测试方案

• 方案包含的内容：测试环境、测试数据、测试模型、性能模型、压力策略、准入准出和进度风险

1.5性能监控

• 要有分层、分段的能力，要有全局监控、定向监控的能力

1.6性能测试要有预定的条件

• 这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容

1.7性能测试中要有场景

• 在既定的环境(包括动态扩展等策略)、既定的数据(包括场景执行中的数据 变化)、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状 态参数变化，并实时判断分析场景是否符合预期
• 场景分类：基准性能测试、容量性能场景、稳定性性能场景、异常性能场景

1.8性能测试的分析调优

性能项目分类

• 新系统性能测试类:这样的项目一般都会要求测试出系统的最大容量
• 旧系统新版本性能测试类:这样的项目一般都是和旧版本对比，只要性能不下降就可以 根据历史数据推算容量，对调优要求一般都不大。
• 新系统性能测试优化类:这类的系统不仅要测试出最大容量，还要求调优到最好。

1.9性能测试肯定要有结果报告

• 内容包含：调优前后的TPS、响应时间、资源对比图

 

1.20TPS和响应之间（RT）是什么关系

• 在实际的性能测试中，假设以梯度递增并发用户数，那么一开始TPS是缓慢上升的，此时RT会有一段时间维持在较低的水平；随着压力继续增大，TPS也会上升，RT也缓慢上升；当TPS达到极限，而压力依旧继续增大时，RT会极速上升，最后到达超时

二、性能指标

2.1需求指标

• 业务指标
  • 业务层面的指标，如业务方要求1000万在线用户，那么继续可以拆分为n个性能场景，每个性能场景中也有对应的定值的业务比例
• 技术指标
  • RT 响应时间（ReSponse Time），通常所说的响应时间，包含了Request Time和Response Time
  • HPS 每秒点击数（Hit Per Second）
  • TPS 每秒事务数（Transactions Per Second）
  • QPS 在mysql中指每秒sql数
  • RPS 每秒请求数
  • CPS HTTP返回码每秒
  • PV 页面浏览量
  • UV 独立访问者
  • IP 独立IP数
  • Throughput 吞吐量
  • IOPS 通常描述磁盘

2.2性能指标概念

• TPS

  • 需要根据场景来定义TPS的粒度；如果是接口层性能测试，那么T是接口级；如果是业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。

• 并发用户数

  • 绝对并发：同一时刻的并发数
  • 相对并发：一个时间段内的并发数
  • 用TPS来承载并发的概念

• 在线用户数和并发用户数

  • 在线用户数指的是某段时间内在系统上的用户，这些用户并不一定会执行动作
  • 并发用户数指定是上述的在线用户某段时间内对某个服务进行动作时的用户数目（并发用户数 = 在线用户数 * 并发度 ）

• 公式

 

性能分析思路

• 总体思路
  • 瓶颈的精准判断
  • 线程递增的策略
  • 性能衰减的过程
  • 响应时间的拆分
  • 构建分析决策树
  • 场景的比对
• 瓶颈的精准判断
  • TPS曲线
    
  • 假设线程是等比例递增的，对于上面那个图，我们可以看到在第二阶梯已经出现性能瓶颈了，因为理论来说第二阶梯的TPS应该是第一阶梯的两倍，然而实际并不是，所以出现了性能瓶颈
  • TPS的意义（从TPS曲线得到的信息）
    • 有没有瓶颈:其实准确说所有的系统都有性能瓶颈，只看我们在哪个量级在做性能测试 了。
    • 瓶颈和压力有没有关系:TPS 随着压力的变化而变化，那就是有关系。不管压力增不增 加，TPS 都会出现曲线趋势问题，那就是无关。
  • 响应时间曲线
    • TPS曲线和响应时间曲线的着重点
      • 响应时间是用来判断业务有多快的，而 TPS 才是用来判断容量有多大的。
• 线程递增的策略
  • 两种线程递增场景
  • 总结
    • 对一个系统来说，如果仅在改变压力策略(其他的 条件比如环境、数据、软硬件配置等都不变)的情况下，系统的最大 TPS 上限是固定的。
    • 关于秒杀场景的测试，前期一定要做好预热，预热指的是有一定的流量在跑，然后在突增压力，这样的比较类似于实际场景；而不是直接一次就大流量进入系统。
• 性能衰减的过程
  • 只要每线程每秒的 TPS 开始变少，就意味着性能瓶颈已经出现了。 但是瓶颈出现之后，并不是说服务器的处理能力(这里我们用 TPS 来描述)会下降，应该 说 TPS 仍然会上升，在性能不断衰减的过程中，TPS 就会达到上限。
• 响应时间的拆分
• 构建分析决策树
  • 它是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思 路的梳理。它起的是纵观全局，高屋建瓴的指导作用。
• 场景的比对
  • 当你觉得系统中哪个环节不行的时候， 又没能力分析它，你可以直接做该环节的增加。

参数化数据

• 参数化逻辑
  • 分析业务场景
  • 罗列出需要参数化的数据及相对应的关系
  • 将参数化数据从数据库中取出或设计对应的生成规则
  • 合理地将参数化数据保存在不同的文件中
  • 在压力工具中设置相应的参数组合关系，以便实现模拟真实场景

性能场景：做参数化之前需要考虑的内容

• 需要关注的数据
  • 参数化数据、监控数据和基础铺底数据

参数化数据

• 参数化数据可能出现的情况
  • 数据不均衡
  • 参数化数据量不足

参数化数据的疑问

• 参数化数据应该用多少数据量?

• 参数化数据从哪里来?

  • 参数化数据主要分为两类
    • 用户输入的数据在后台数据库中已存在，比如我们上面示例中的用户数据。
      • 数据特点：存在后台数据库中;需要用户主动输入;用户输入的数据会和后台数据库中的数据做比对。
      • 这类数据必须查询数据库之后再参数化到工具中。
    • 用户输入的数据在后台数据库中不存在。在业务流中，这些数据会 Insert 或 Update 到数 据库中。
      • 数据特点：数据库中原本不存在这些数据;在脚本执行成功后会将这些数据 insert 或 update 到数据库中;每个用户输入的数据可能相同，也可能不同，这取决于业务特点。
      • 这类数据必须通过压力工具做参数化，同时也必须满足业务规则。
        • 数据满足条件：要满足生产环境中数据的分布;要满足性能场景中数据量的要求。

• 参数多与少的选择对系统压力有什么影响?

  • 参数取得过多，对系统的压力就会大;参数取得过少，不符合真实场景中的数据量，则无法 测试出系统真实的压力。

• 参数化数据在数据库中的直方图是否均衡?

  • 指的是每个用户的数据分布是否符合业务场景；比如同样是下单业务，给用户A造了几十万数据，给用户B造了几条数据，明显就是不合理的

性能场景设计

前期工作

• 确认需要压测的业务，以及这些业务对应的业务比例（可以从日志中获取）
• 确定业务目标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	内存交换区进入内存的内存大小

中间件

• 消息队列

  • 指标包括：生产速度和消费速度
  • 假设发现rabittmq出现消息堆积，解决办法
    • 增加消费者（这种原因是消费速度跟不上生产速度）
    • 若增加消费者也不能解决，那么有可能是服务端出bug了，导致无法消费

• redis

• mysql

操作系统常用计数器

• 命令模块
• CPU参数含义
  • us CPU 是用户态进程消耗的 CPU 百分比
  • wa cpu是 I/O 读写等待消耗的 CPU 百分比。
  • sy CPU 是内核消耗的 CPU 百分比
  • si CPU 是软中断消耗的 CPU 百分比

作者：杰克卡霍
链接：https://juejin.cn/post/6844904196454481927
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

标签：总结,定位,场景,性能,TPS,测试,参数,数据,CPU
From： https://www.cnblogs.com/uestc2007/p/17508129.html