性能测试常见指标

性能指标分类

在进行性能测试的指标监控和结果分析时，可以关注以下这几个维度的指标：

• 系统性能指标
• 资源性能指标
• 数据库指标
• 中间件指标
• 稳定性指标
• 可扩展性指标
• 可靠性指标

一、系统性能指标

系统性能指标，几种常见的：

• 并发用户数
• 错误率
• 响应时间
• 系统处理能力：TPS、QPS、HPS
• 吞吐量

1、并发用户数

• 定义
  同一时刻，在系统中进行业务操作的用户数量
• 在不同类型系统的区别；长连接和短连接
  1.在长连接型系统（如即时通讯系统）中，最大并发用户数就是该系统的最大并发接入能力。由于需要维持长连接，所以并发用户数多对服务器资源也是个负担（CPU/内存/网卡等）
  2.在短连接型系统（如web网站）中，最大并发用户数并不等于该系统的最大并发介入能力，而是和该系统架构、系统处理能力等情况有关（请求的处理能力、短连接的释放时机等考虑）
• 使用
  1.单接口：测试的是这个接口在该并发用户数的情况下的性能
  2.业务逻辑：测试业务逻辑，需要考虑到系统中不同用户的不同使用场景，并不是所有用户都在用系统的同个功能。比如说100个在线用户，有40%在浏览商品，有30%在下订单，有30%在支付（比例是瞎掰）

2、错误率

• 定义
  系统在负载情况下，请求失败的比率。错误率 = (失败请求数 / 总请求数)* 100%，或者 (失败交易数 / 总交易数)* 100%
• 行业参考标准
  不同行业不同业务系统，性能指标中，对高并发情况下的错误率的要求不一致，但大多不能大于0.06%

3、响应时间

• 定义
  简称RT，指的是系统对请求作出响应的时间。有两种理解，一种前端视角，一种是后端视角：关注后端的性能测试，基本是接口级别的测试。所以响应时间是从 C 端发出请求开始计算，直到 C 端收到最后一个字节的响应数据（也称之为TTLB，Time to laster byte）。也就是下图中的N1+T3+T4+T5+T6+T7+T8m
  图示

  请求响应的过程

• 解释
  响应时间的单位一般为毫秒或秒。在一个系统中，有很多个功能，对应不同的接口，拥有不同的处理逻辑，所以不同的功能的响应时间一般不相同。就算是相同的接口，可能不同的入参会导致响应时间也不一样（比如提交表单）。所以，在执行系统的性能测试时的响应时间，一般指该系统参与性能测试的这些功能的平均响应时间，或者这些功能中的最大响应时间

• 行业参考标准
  互联网上对响应时间有一个标准：2-5-10原则
  2秒之内得到响应，会认为系统响应的很快
  5秒之内得到响应，会认为系统响应的速度还不错
  10秒之内得到响应，会认为系统响应的速度很糟糕
  超过10秒还未得到响应，会认为系统是没有响应的
  本段摘抄自性能测试的指标
  除了这个原则，还需要根据不同行业不同类型系统，不同数据量，结合不同场景来制定性能指标中的响应时间。因为响应时间并不能直接说明这个系统的性能高低，而是取决于在使用场景中，用户对响应时间的接受程度

4、系统处理能力：HPS、TPS、QPS

• 定义
  指系统在利用系统硬件平台和软件平台进行信息处理的能力。
  系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般建议与系统交易日志保持一致，以便于统计业务量或者交易量。
• 解释
  HPS（Hits Per Second）：每秒点击次数，单位是次/秒。
  TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
  QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。
  在互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS。一般情况下，用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。
• 行业参考标准
  无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好。
  根据经验，一般情况下：
  金融行业：1000TPS~50000TPS，不包括互联网化的活动
  保险行业：100TPS~100000TPS，不包括互联网化的活动
  制造行业：10TPS~5000TPS
  互联网电子商务：10000TPS~1000000TPS
  互联网中型网站：1000TPS~50000TPS
  互联网小型网站: 500TPS~10000TPS

5、吞吐量/Throughput

• 定义
  吞吐量是指系统在单位时间内处理请求的数量。
• 解释
  对于单用户的系统，响应时间可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
  对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当但有n个用户使用时，每个用户的响应时间通常并不是n×t，而往往比n×t小很多（不过，在某些特殊情况下也可能比n×t大，甚至大很多）。
• 一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

• Jmeter中吞吐量的计算
  吞吐量 = 总线程数 / 执行持续时间（单位：x个线程/s）
  执行持续时间 = 最后一个线程的启动时间 + 最后一个线程的持续时间 - 第一个线程的启动时间

  
  示意图

二、资源性能指标

资源性能指标，几种常见的：

• CPU
• 内存
• 磁盘IOPS
• 磁盘吐吞量
• 网络吐吞量
  在执行性能测试时，如果系统是分服务部署的，那么需要监控所测功能接口的服务器所在的服务器的资源指标（比如es部署在服务器A，mysql部署在服务器B，核心业务服务部署在服务器C...）；如果所有服务都只在一个服务器，那么只需要监控该服务器的资源指标即可

1、CPU/中央处理器

• 定义
  CPU是一块超大规模的集成电路，是计算机的控制核心和运算核心。功能主要是解释计算机指令以及处理软件中的数据
• 行业参考标准
  1.CPU的指标主要是看CPU利用率，监控过程注意总的利用率和服务的利用率（因为两者未必相等）
  2.CPU总的利用率应该少于80%甚至少于75%
• CPU执行状态（详情百度）
  1.用户态/user
  2.系统态/sys：要小于等于30%
  3.等待态/wait：要小于等于5%
  4.空闲态/idle

2、内存

• 定义
  内存是计算机中十分重要的结构之一，是和CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的（进程线程），所以内存的性能对计算机的性能、程序的性能影响非常大。
• swap
  swap空间是虚拟内存技术的一种，可以是硬盘上的一块区域，或分区，或文件，也可以是分区和文件结合。当物理内存资源紧张时，操作系统会把一些不常访问的数据存放到swap中，为其他常用的进程腾出物理内存，当要访问swap的数据时，操作系统会再从swap中加载这部分数据到内存中。
  ps.如今swap空间限制是2G，而不是128M

• 行业参考标准
  一般情况下，服务器都会配置swap空间。此时，当内存利用率达到100%时，并不代表内存有瓶颈，还需要结合看swap空间的利用率，一般情况下，swap空间的利用率要低于70%，太高的话容易导致系统性能降低
  相关的命令：free -m、vmstat 3(刷新时间)、swapon -s
  参考：文章1、文章12

3、IOPS

• 定义
  IOPS (Input/Output Per Second)即每秒的输入输出量/读写次数，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

• 计算公式
  1、常见磁盘平均物理寻道时间为：
  7200转/分的STAT硬盘平均物理寻道时间是9ms
  10000转/分的STAT硬盘平均物理寻道时间是6ms
  15000转/分的SAS硬盘平均物理寻道时间是4ms
  2、常见硬盘的旋转延迟时间为：
  7200 rpm的磁盘平均旋转延迟大约为601000/7200/2 = 4.17ms
  10000 rpm的磁盘平均旋转延迟大约为601000/10000/2 = 3ms，
  15000 rpm的磁盘其平均旋转延迟约为60*1000/15000/2 = 2ms。
  3、最大IOPS的理论计算方法
  IOPS = 1000 ms/ (寻道时间 + 旋转延迟)。可以忽略数据传输时间。
  7200 rpm的磁盘IOPS = 1000 / (9 + 4.17) = 76 IOPS
  10000 rpm的磁盘IOPS = 1000 / (6+ 3) = 111 IOPS
  15000 rpm的磁盘IOPS = 1000 / (4 + 2) = 166 IOPS

• 行业参考标准
  IOPS可细分为如下几个指标：
  Toatal IOPS：混合读写和顺序随机I/O负载情况下的磁盘IOPS，这个与实际I/O情况最为相符，大多数应用关注此指标
  Random Read IOPS：100%随机读负载情况下的IOPS。
  Random Write IOPS：100%随机写负载情况下的IOPS。
  Sequential Read IOPS：100%顺序读负载情况下的IOPS。
  Sequential Write IOPS：100%顺序写负载情况下的IOPS。

• 相关命令
  iostat：查看IO状态

4、磁盘吞吐量

• 定义
  磁盘吞吐量/Disk Throughput，指的是磁盘正常情况下，单位时间内经过磁盘的数据量（磁盘写入和读出的数据量），也就是每秒磁盘I/O的流量。

• 行业参考标准
  最能直接反应出磁盘是否有瓶颈的依据，就是磁盘的使用率。一般情况下，使用率要低于80%甚至70%

• 相关命令
  df和du：查看磁盘使用情况
  iostat：查看IO状态

磁盘IOPS和磁盘吞吐量

• 计算
  每秒 I/O 吞吐量＝ (IOPS) * (平均 I/O SIZE)。
  从公式可以看出： (I/O SIZE 越大)，IOPS 越高，那么每秒 I/O 的吞吐量就越高。因此，我们会认为 IOPS 和吞吐量的数值越高越好。
  实际上，对于一个磁盘来讲，这两个参数均有其最大值，有上限，而且这两个参数也存在着一定的关系。

• 场景
  1.追求吞吐量的场景：读取1个10MB文件，用时0.2秒 Throught(吞吐量)=50MB/s, IOPS=5
  2.追求IOPS的场景：读取10000个1KB文件，用时10秒 Throught(吞吐量)=1MB/s ，IOPS=1000/s

5、网络吞吐量

• 定义
  网络吞吐量/Network Throughput，是指在正常情况下单位时间内通过的网络的数据数量，单位为Byte/s。
  网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。
  当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。

• 行业参考标准
  网络吞吐量一般情况下不能超过设备或链路的最大传输能力的70%

• ipraf命令
  安装使用
  命令详解

三、数据库指标

• 常用的数据库指标：

一级指标	二级指标	单位	解释
SQL	耗时	微秒	执行SQL耗时
吞吐量	QPS	个	每秒查询次数
吞吐量	TPS	个	每秒事务次数
命中率	Key Buffer命中率	百分之	索引缓冲区命中率
命中率	InnoDB Buffer命中率	百分比	InnoDB缓冲区命中率
命中率	Query Cache命中率	百分比	查询缓存命中率
命中率	Table Cache命中率	百分比	表缓存命中率数
命中率	Thread Cache命中率	百分比	线程缓存命中率
锁	等待次数	次	锁等待次数
锁	等待时间	微秒	锁等待时间

• 行业参考标准
  1.执行SQL耗时越小越好，一般是微妙级
  2.锁等待次数越少越好，锁等待时间越短越好
  3.命中率越高越好，一般不能低于95%

• 实践
  笔者在性能测试实践中，在mysql方面的关注点：
  1.执行sql耗时
  2.数据库的连接数
  3.数据库锁
  上面三种指标，彼此相互影响，可以通过打点输出日志来监控

• 缓存的利弊
  mysql查询缓存可以改善性能，但是使用的时候需要注意：开启查询缓存后，读写会增加额外的开销。因为读的时候，会先去查询缓存；写的时候，在写入数据后需要更新缓存。不过，一般情况下这些消耗都相对比较小，所以查询缓存一般情况下还是优大于弊。当然，最终是否需要开启查询缓存，需要结合业务的需求。

• 扩充知识
  性能测试：数据库

四、中间件指标

常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC,具体如下：

一级指标	二级指标	单位	解释
GC	GC频率	每秒多少次	java虚拟机垃圾部分回收频率
GC	Full GC频率	每小时多少次	java虚拟机垃圾完全回收频率
GC	Full GC平均时长	秒	用于垃圾完全回收的平均时长
GC	Full GC最大时长	秒	用于垃圾完全回收的最大时长
GC	堆使用率	百分比	堆使用率
ThreadPool	Active Thread Count	个	活动的线程数
ThreadPool	Pending User Request	个	处于排队的用户请求个数
JDBC	JDBC Active Connection	个	JDBC活动连接数

• 行业参考标准：
  1.当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。
  2.当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。
  3.GC 频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适。

五、稳定性指标

• 定义
  稳定性测试一般是在系统最大容量的80%或者系统预期日常压力下进行的，关注的指标有：TPS曲线、资源指标变动、最短的稳定时间

• 解释
  最短稳定时间是基于下面两点得出：
  1.TPS曲线稳定，没有太大的波动
  2.资源指标没有出现泄漏等异常情况

• 行业参考标准
  对于不同使用率的系统，最短稳定时间有不同的要求：
  1.对于日常工作使用的系统（运行8-9小时），最短稳定时间至少要8个小时
  2.对于7*24小时运行的系统，最短稳定时间至少要24小时，并且需要考虑到使用高峰期。
  如果系统不能稳定运行，上线之后，随着业务的增长，以及长时间的系统运行，将会出现性能下降，甚至有系统崩溃的风险

六、可扩展性指标

• 定义
  可扩展性指的是系统在以集群方式进行部署时，增加的硬件资源和增加的性能指标之间的关系
• 计算公式
  扩展指标 = ( 增加的性能 / 之前的性能) / ( 增加的资源 / 之前的资源) *100%
• 解释
  扩展能力是通过多轮的资源增加以及对应的性能测试来得出的指标趋势图。扩展能力非常好的系统，扩展指标应该是线性的或者接近线性的。
• 行业参考标准
  理想的扩展能力是资源增加几倍，那么性能增加至少是其70%

七、可靠性指标

从你系统可靠性指标度量分析时，可以从三类进行：

• 双机热备
• 集群
• 备份和恢复

1、双机热备

对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：

• 节点切换是否成功及其消耗时间。
• 双机切换是否有业务中断。
• 节点回切是否成功及其耗时。
• 双机回切是否有业务中断。
• 节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

2、集群

对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：

• 集群中某个节点出现故障时，系统是否有业务中断情况出现
• 在集群中新增一个节点时，是否需要重启系统
• 当故障节点恢复后，加入集群，是否需要重启系统
• 当故障节点恢复后，加入集群，系统是否有业务中断情况出现
• 节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

3、备份和恢复

本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的- - 备份和恢复，包括以下测试内容：

• 备份是否成功及其消耗时间。
• 备份是否使用脚本自动化完成。
• 恢复是否成功及其消耗时间。
• 恢复是否使用脚本自动化完成指标体系的运用原则。
• 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
• 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
• 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
• 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
• 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。

总结

上面所描述的一些点，比如说：可扩展性指标、可靠性指标，甚至中间件指标等，都是在大部分公司大部分项目中是不会去进行的，但是从产品的整体性能和质量保证的角度来看，却是必须要关注的。
工作过程中，制定什么样的测试方案，需要关注哪些指标，需要结合项目实际情况（包括但不仅限于产品需求、项目时间、可提供设备、人员素质等方面）

---

PS.本文整理自性能专题：一文搞懂性能测试常见指标