阿里P7大佬，告诉你性能指标中那些你不知道的事

Posted 2021-07-05 七月的小尾巴

前言

在做性能测试的时候，我们关注了很多性能测试指标，但是这些指标，你真的懂了吗？

事务

在性能测试领域里，衡量一个系统性能的好坏，主要是看单位时间内，系统可以处理多少业务量，各个系统的业务不同，为了方便使用同一指标来衡量业务性能。用事务来代表业务操作，一个事务可以代表一个业务，也可以代表多个业务操作。事务是用户定义的，想测试什么业务的性能，就把业务加到事务中。

TPS/QPS

Transction Per Second 每秒处理的事务数

性能测试指标-TPS

如上图所示，我们测试 下单 业务，将下单接口定义为一个事务，
测试 添加购物车-下单 整体业务将两个接口定义为一个事务 。事务可以是一个接口，也可以是多个接口。

响应时间

一个请求的响应时间都包含哪些时间？

下面一张图，可以清晰的描述出一个网络过程中会发送哪些请求

图中是通过 LoadRunner 发送请求到网络设备（如路由器），然后再到中间件（如负载均衡），再到应用程序，最终到数据库完成一整个流程。

• 响应时间 = 网络传输的总时间 + 各组件业务处理时间
• 平均响应时间：在测试过程中，所有请求的平均耗时

TOP响应时间

TOP响应时间是将所有请求先从大到小进行排序，计算指定比例的请求都是小于每个时间。该指标统计的最大多数请求的耗时。

1. TP90%（90%的响应时间）：90%的请求耗时都低于某个时间
2. TP95%（95%的响应时间）：95%的请求耗时都低于某个时间
3. TP99%（99%的响应时间）：99%的请求耗时都低于某个时间

相信很多朋友在做性能测试的时候，都知道这个响应时间，但是如果在面试过程中，被问到这个百分比具体是什么计算的呢？

下面我们用这个excel中的数据为例：

假设我们有100个请求，然后100个请求，我们都按照响应时间从大到小排序，假设我们需要计算95%的响应时间，即从序号1开始计算，一直数到第5个，第五个请求的响应时间为643ms，那么95%的响应时间为643ms

接口响应时间的衡量标准

通常来说，一般性能响应时间没有具体的衡量标准，根据需求而定。那么在没有需求的情况下，大多数公司，如一些高频的业务的接口，时间不能高于100ms，如果是低频的业务，则时间不能超出200ms。（这里说的并非强制约束，属于一些一线公司的一些规范）

• 100ms以下：说明接口性能较好
• 100-200ms：性能还行
• 超过500ms：性能较差
• 超时1s：性能极差

并发数 / 虚拟用户（Vuser）

压测工具中设置的并发线程 / 进程数量

成功率

统计所有请求的成功率，通常来说，我们都希望成功率可以达到100%，这个是最佳的状态。

PV （Page View）

页面 / 接口的访问量

通常比如我们打开一个 APP，那么我们每打开一次，则PV就会统计一次。公司中 PV 主要是用来统计我们的访问量。

UV（Unique Visitor）

UV指的是页面/接口每日唯一访客。如我们打开APP，一天中打开了10次，那么UV只会统计一次，通常在程序中会根据UV去重。UV 主要是用来统计我们的每日的用户量

吞吐量

网络中上行和下行的流量总和，（如我们再QQ中发送文件，发送文件的操作我们称为上行，下载文件，我们从QQ服务器下载资源，则为下行）吞吐量代表网络的流量，TPS越高，吞吐量越大。

TPS、响应时间和并发数的关系

在性能测试过程中，TPS、响应时间和并发数是我们注重关注的指标。那么这三个指标有什么关系呢？

• 在系统达到瓶颈之前，TPS和并发数成正比
  TPS = 1 / 响应时间 * 并发数
  TPS = 并发数 / 响应时间（s）

• 响应时间和TPS成反比

操作系统级别监控

cpu使用率、内存使用率、网络IO、磁盘

中间件监控

连接数、长短连接、使用内存

应用层监控

线程状态、JVM参数、GC频率、锁

DB层监控

连接数、锁、缓存、内容、SQL效率

性能测试流程

• 需求调研
• 测试计划
• 测试环境
• 数据准备
• 脚本编写
• 压测执行
• 调优回归
• 测试报告

需求调研

• 项目背景
• 测试范围
• 业务逻辑 & 数据流向
• 明确业务逻辑及数据流向，数据流向指的是数据插入哪一张表，有没有进入缓存，或者是否第三方接口。
• 系统架构
• 做性能测试需要注意性能测试的瓶颈和调优，所有我们需要了解系统的架构，如数据库、负载均衡等（通常架构信息问开发获取）
• 配置信息
• 需要跟运维和开发确认，线上部署的环境，cup多少核，内存几G
• 测试数据量（量级要一致）
  指的是本次测试，我们需要基于多少测试数据去测
• 外部依赖
• 外部依赖，通常使用 Mock 数据
• 系统使用场景，业务比例
• 日常业务量
• 预期指标
• 上线时间

性能测试计划

• 项目描述
• 业务模型及性能指标
• 测试环境说明
• 测试资源
• 测试方法及场景设计原则
• 基准测试

基准测试，指的是如登录场景，我们用一个登录用户，一直跑3分钟左右，
那么我们可以看到登录的场景每秒钟可以TPS，响应时间。
做基准测试的意义主要是如后期我们更新，或者项目业务迭代，
那我们之后对于这个场景，有一个参考。

特点：单并发

• 单交易负载测试-必做
  （单独测试某一个接口）
• 混合场景测试-必做

结合业务混合测试，对于线上的业务场景，都是混合场景

• 高可用性测试

主要是针对线上的集群测试，如线上有10台机器，如果集群里面某一台机器挂了，
那么其他的机器是否会受影响，挂的机器重启之之后，业务是否能正常使用。通常出现问题
都是架构师，在设计框架的时候，存在一定的问题。

• 异常场景测试（如弱网情况）

• 稳定性测试-必做

部分性能问题，通常十几分钟是很难暴露出来的，所以我们通常会在最后持续去跑
十几甚至几十个小时，去观察系统的稳定性。

• 其他特殊场景测试
• 测试进度安排及测试准测

注意要点

• 测试机硬件配置尽量和线上一致
• 系统版本与线上一致
• 测试环境部署线上最小单元模块
• 应用、中间件、数据库配置要与线上一致
• 其他特殊配置

性能测试流程-数据构造

测试数据通常分为两部分：基础数据和参数化数据
通常采用以下三种方法进行构造

• 业务接口
• 适合数据表关系复杂
• 优点：数据完整性比较好
• 存储过程
• 适合表数量少，简单
• 优点：速度最快
• 脚本导入
• 适合数据逻辑复杂
• 自由度比较高

脚本编写

• 选择工具（LR、JMeter、Locust等）
• 选择协议（Http、TCP、RPC)
• 参数化
• 关联
• 检查点（断言）
• 事务判断
• 分布式执行
• 监控
• Linux
• JVM
• 数据库
• 收集测试结果
• 数据分析
• 瓶颈定位

调优回归

首先，大家需要注意的是，性能没有绝对的好坏，适合公司的才是最好的，比如公司一个的登录接口，每秒的TPS只有10，但是对于该公司而言，完全够用。

• 性能调优需要整个团队完成
• 反复尝试
• 回归验证
• 监控工具
• 全链路排查
• 日志分析
• 模块隔离

测试报告