性能测试简单介绍

• 说明：
a 点：性能期望值
b 点：高于期望，系统资源处于临界点
c 点：高于期望，性能处于拐点
d 点：超过负载，资源不够用，系统处于崩溃

性能测试目的

• 最大限度的满足用户的需求，为了验证以下需求以及目标进行性能测试

Ø 评估系统的能力

Ø 寻找系统的瓶颈

Ø 检查系统的在性能测试下的系统 bug

Ø 验证稳定性、可靠性、扩展性、负载均衡

 性能测试指标介绍

RT	Response time	通常我们说响应时间都是从请求发出到请求返回这期间消耗的时间，不包括浏览器渲染时间
TPS	Transaction per second	每秒事务数
QPS	Queries per second	Mysql中的每秒SQL数
RPS	Request per second	每秒请求数
PV	Page view	页面浏览量
UV	Unique view	独立访问者

性能模型设计

计算出高峰期的平均TPS

request/sec 或者PV的模型，日志分析得来或者监控线上的请求得来例如

• 总的 TPS 计算： TPS= request 总量 *80%/24*80%*3600 ， 此 TPS 均值作为性能测试需要达到

业务模型比例计算过程

交易1	524567	20%
交易2	34567	15. 18%
交易3	567890	23%

监控指标

CPU占用率	对一个时间段内CPU使用状况的统计。 建议：<80%
Load Average	一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。 建议：<0.7*CPU个数*核数
磁盘I/O	%util所有处理IO的时间（在统计时间内）/ 总共统计时间；--衡量IO的繁忙程度<60%, IOwait 指在一个采样周期内有百分之几的时间是属于以下情况：CPU处于空闲状态并且至少有一个未完成的磁盘IO请求<30%
Memory	程序的可用内存/物理内存<10%, 且用vmstat 命令查看so si 值不为0
SWAP	swap space 是磁盘上的一块区域，当系统物理内存吃紧时，Linux 会将内存中不常访问的数据保存到 swap 上，这样系统就有更多的物理内存为各个进程服务，而当系统需要访问 swap 上存储的内容时，再将 swap 上的数据加载到内存中，这就是常说的换出和换入, 有没有交换页面. 同时结合vmstat so si

性能执行的策略

场景分为四类：基准测试、单交易、容量、稳定性、异常每个场景都对应着不同的目标，

基准场景是为了找到系统中明显的配置及软件bug,同时也为容量场景提供可以对比的基准数据

• 1. 单交易场景

• 单交易是容量测试的前奏分别验证测试模型中每支关键交易所对应应用服务是否存在并发性问题，同时获取最大的 TPS ，为将来容量场景的测试和性能分析提供参考，并验证单支交易是否满足业务需求，分析单个接口的瓶颈点在哪里，找到系统中明显的配置及软件 bug, 同时为容量常场景提供可对比的基准数据，如果 TPS 没有超过要求 TPS 需要调优。

• 获取单接口最大 TPS

• 解决单接口基准场景中遇到的性能问题

• 为容量场景提供参考

• 验证是否满足业务需求

2容量场景

• 对于容量场景来说，最重要的就是业务比例 即业务模型，根据测试模型配比模拟高峰期实际业务操作验证系统在混合交易下是够满足业务需求，在达到指标要求后保证模型的前提下继续进行梯度加压，直到出现性能瓶颈为止，获取各项性能指标数据

• 最大 TPS 是最大稳定的 TPS

• 找到系统瓶颈

3稳定性场景

• 稳定性测试时间长度取决于系统上线后的运维周期，一段时间运维数据

• 稳定性场景需要的运行时间计算

• 稳定性使用的 TPS 量级的合理，

4.异常场景

• 针对系统的架构，先分析异常场景中的需求点，再设计相应的案例来覆盖

• 一般异常有两大类： 1 架构级的异常， 2 容量引起的性能异常

• 用 50% 压力进行异常性测试，

• 类似可靠性测试，

验证应用，数据库服务器再可靠性，容错性失效恢复能力

•性能分析

瓶颈的定位

首先理解瓶颈，系统处理能力即TPS处理中遇到了关键的阻碍，即系统计入重负载区（一个系统资源或者多个系统资源到达了饱和值）

测试报告：

单交易负载测试是逐一对业务模型中的每支交易进行单个交易多并发测试，目的是排除单交易存在的问题和性能瓶颈，为混合场景的测试做准备。

方法：

在系统无压力时，使用各单交易脚本、以满足业务需求的TPS，(详细配置如下表，具体并发用户以实际情况实时调整）的负载序列运行脚本5分钟，记录交易的平均响应时间、平均TPS

混合场景：

按照业务配比模拟生产环境高峰时间段实际情况操作，逐步加压验证系统是否能满足各项性能指标，在达到指标后，保证模型的前提下继续进行梯度加压，直到出现性能饱和，获取各项性能指标数据。

方法：

参考“单交易负载测试”响应时间结果，依据测试模型配置并发数，设计场景(50U、100U、150U)，按照梯度加压的方法，逐步提升对系统的压力，每个梯度执行5分钟，记录每个梯度测试时各项性能指标数据，直到系统达到目标为止，获取各项性能指标数据。继续在保证模型的前提下进行梯度加压，直到出现性能饱和为止，获取各项性能指标数据。

• 稳定性测试：

描述：

对于7×24运行的系统，至少应该能够保证较高压力下系统稳定运行48小时以上。故本次稳定性测试是在当前基础数据上保持系统高峰压力80%情况（TPS=1600=2000 * 80%笔/秒）采用联机交易持续运行48小时，通过检查系统的各项性能指标、交易成功率、系统资源消耗情况，来验证系统长时间运行的稳定性。

方法：

加载所有脚本，采用系统业务要求的最大处理能力80%的压力（TPS=2000 * 80%）连续运行48小时，记录系统的各项性能指标、交易成功率、系统资源消耗情况等。

• 可靠性测试：

描述：

验证系统的可靠性，包括容错性、失效恢复能力等。

方法：

1. 容错性测试方法：依据测试模型发起OTP系统处理能力50%的压力，对单点应用分别进行停服务（正常停止和KILL）、宕机、拔网线（宕网卡） 等异常操作后，部分交易短暂失败后是否可以自动路由到另一节点，交易是否可以马上恢复。
2. 失效恢复测试方法：恢复模拟的异常，确认系统的失效恢复能力。记录平均失效恢复时间（MTTR），交易处理能力恢复水平（%），交易错误率（%），交易响应时间，系统资源使用情况。

• 同一交易不同并发梯度下的响应时间增长率同TPS的增长率成正比，在达到业务需求的TPS时，响应时间均满足测试指标；
• 与基准测试结果比较，并发量增加，随着TPS的增加，响应时间是逐步增加的，在数据库资源消耗不大的情况下，TPS 就能达到业务需求，响应时间也是完全满足业务需求；