性能专题：一文搞懂性能测试常见指标

1. 前言

上周，对性能测试系列专题，在公号内发表了第一篇介绍：【性能系列连载一】开篇：性能测试不可不知的“干货”，但反响貌似并不太好，但既然此前已答应了部分读者要连载分享性能这块的知识，含着泪也得继续写。

性能测试的基础：就是在确保功能实现正确的前提下，经过合适的性能测试加压方式和策略，并收集考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用状况，来评估是否存在性能问题隐患。

那今天做为性能测试系列的第二篇，主要会为你们介绍在服务端性能测试中，常见的性能指标有哪些。

2. 性能指标分类

从性能测试分析度量的度角来看，能够从以下几个维度来收集考察各项性能指标：

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

下面将从如上这几个维度，分别从各自维度常见指标，以及指标含义、指标行业参考标准等方面进行介绍。

3. 系统性能指标

系统性能指标，常见的可从以下几类进行参考：

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

3.1 响应时间

定义和解释：响应时间，简称RT。是指系统对请求做出响应的时间，能够理解为是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。直观上看，这个指标与人对软件性能的主观感觉是很是一致的，由于它完整地记录了整个计算机系统处理请求的时间。

在性能检测中通常以压力发起端至被压测服务器返回处理结果的时间为计量，单位通常为秒或毫秒，因为一个系统一般会提供许多功能，而不一样功能的处理逻辑也千差万别，于是不一样功能的响应时间也不尽相同，甚至同一功能在不一样输入数据的状况下响应时间也不相同。因此，在讨论一个系统的响应时间时，一般是指该系统全部功能的平均时间或者全部功能的最大响应时间。

行业参考标准：

不一样行业不一样业务可接受的响应时间是不一样的，通常状况，对于在线实时交易：

• 互联网企业：500毫秒如下，例如淘宝业务10毫秒左右。
• 金融企业：1秒如下为佳，部分复杂业务3秒如下。
• 保险企业：3秒如下为佳。
• 制造业：5秒如下为佳。
• 时间窗口：不一样数据量结果是不同的，大数据量的状况下，2小时内完成。

须要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。

3.2 系统处理能力

定义和解释：系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力经过系统每秒钟可以处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标均可以评价应用系统的处理能力。

通常状况下，系统处理能力又用如下几个指标来度量：

• 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

3.3 吞吐量

定义和解释：吞吐量是指系统在单位时间内处理请求的数量。

对于单用户的系统，响应时间能够很好地度量系统的性能，但对于并发系统，一般须要用吞吐量做为性能指标。

而对于一个多用户的系统，若是只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每一个用户看到的响应时间一般并非n×t，而每每比n×t小不少（固然，在某些特殊状况下也可能比n×t大，甚至大不少）。通常而言，吞吐量是一个比较通用的指标，两个具备不一样用户数和用户使用模式的系统，若是其最大吞吐量基本一致，则能够判断两个系统的处理能力基本一致。

3.4 并发用户数

定义和解释：并发用户数指在同一时刻内，登陆系统并进行业务操做的用户数量。

并发用户数对于长链接系统来讲最大并发用户数便是系统的并发接入能力。对于短链接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各类状况相关。

与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个很是不许确的指标，由于用户不一样的使用模式会致使不一样用户在单位时间发出不一样数量的请求。

3.5  错误率

定义和解释：错误率简称FR，指系统在负载状况下，失败交易的几率。错误率＝(失败交易数/交易总数)*100%。

行业参考标准：

不一样系统对错误率的要求不一样，但通常不超出千分之六，即成功率不低于99.4%

4. 资源性能指标

资源性能指标，常见的可从以下几类进行参考：

• CPU
• 内存
• 磁盘吐吞量
• 网络吐吞量

4.1  CPU

定义和解释：CPU又称为中央处理器，是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。

行业参考标准：

CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。

• CPU 利用率要低于业界警惕值范围以内，即小于或者等于75%;
• CPU sys%小于或者等于30%;
• CPU wait%小于或者等于5%；

4.2  内存

定义和解释：内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中全部程序的运行都是在内存中进行的，所以内存的性能对计算机的影响很是大。

行业参考标准：

如今的操做系统为了最大利用内存，在内存中存放了缓存，所以内存利用率100%并不表明内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，通常状况下，SWAP交换空间利用率要低于70%,太多的交换将会引发系统性能低下。

4.3  磁盘吐吞量

定义和解释：磁盘吞吐量简称为Disk Throughput，是指在无磁盘故障的状况下单位时间内经过磁盘的数据量。

行业参考标准：

磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，通常状况下，磁盘繁忙率要低于70%。

4.4  网络吐吞量

定义和解释：网络吞吐量简称为Network Throughput，是指在无网络故障的状况下单位时间内经过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则须要考虑升级网络设备。

行业参考标准：

网络吞吐量指标主要有每秒有多少兆流量进出，通常状况下不能超过设备或链路最大传输能力的70%。

5. 中间件指标

经常使用的中间件例如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活动链接数

 

行业参考标准：

• 当前正在运行的线程数不能超过设定的最大值。通常状况下系统性能较好的状况下，线程数最小值设置50和最大值设置200比较合适。
• 当前运行的JDBC链接数不能超过设定的最大值。通常状况下系统性能较好的状况下，JDBC最小值设置50和最大值设置200比较合适。
• ＧＣ频率不能频繁，特别是FULL GC更不能频繁，通常状况下系统性能较好的状况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适。

6. 数据库指标

经常使用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、链接数等，具体以下：

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

行业参考标准：

• SQL耗时越小越好，通常状况下微秒级别。
• 命中率越高越好，通常状况下不能低于95%。
• 锁等待次数越低越好，等待时间越短越好。

7. 稳定性指标

最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期平常压力）状况下运行，可以稳定运行的最短期。

通常来讲，对于正常工做日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。

对于7*24运行的系统，至少应该可以保证系统稳定运行24小时以上。若是系统不能稳定的运行，上线后，随着业务量的增加和长时间运行，将会出现性能降低甚至崩溃的风险。

参考标准：

• TPS曲线稳定，没有大幅度的波动。
• 各项资源指标没有泄露或异常状况。

8. 可扩展性指标

定义和解释：是指应用软件或操做系统以群集方式部署，增长的硬件资源与增长的处理能力之间的关系。

计算公式为：（增长性能/原始性能）/（增长资源/原始资源）*100%。

扩展能力应经过多轮测试得到扩展指标的变化趋势。通常扩展能力很是好的应用系统，扩展指标应是线性或接近线性的，如今不少大规模的分布式系统的扩展能力很是好。

参考标准：

理想的扩展能力是资源增长几倍，性能就提高几倍。扩展能力至少在70%以上。

9. 可靠性指标

对于服务端性能测试，从系统可靠性指标度量分析时，常见从三类来入手：

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

9.1 双机热备

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

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

9.2 集群

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

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

9.3 备份和恢复

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

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

其中上述提到的【可扩展指标】和【可靠性指标】，大多数公司在开展性能测试的时候不多会涉及到这些测试点，但这些点从产品总体性能和质量角度来说，又是不得不关注的一些重点，算是给你们提供一些测试思路。

 

最后，关注公众号「测试开发技术」，并后台回复me， 可扫码添加做者我的微信号，免费领取《敏捷性能测试分析与规划性能测试》《互联网性能测试案例及经验分享》。

点击可阅读原文：

更多干货，请扫描关注【测试开发技术】