性能测试技术笔记系列（一）之性能指标行业参考｜收藏版
大多数测试人员在谈到性能测试时，往往会倍感压力。对于我来说更是如此，想做好性能测试需要庞大的知识体系，不断实践所总结的经验教训更是弥足珍贵。而且每个人对性能测试的理解都有独到的地方，此次逐步揭开性能测试得神秘面纱，结合课堂学习及自身消化理解后的，归纳了一些性能测试的基础知识，希望对大家理解性能测试有所帮助。
性能测试的基础
就是在确保功能实现正确的前提下，通过合适的性能测试加压方式和策略，并收集考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况，来评估是否存在性能问题隐患。
性能指标分类
从性能测试分析度量的度角来看，可以从如下几个维度来收集考察各项性能指标：
- 系统性能指标
- 资源性能指标
- 中间件指标
- 数据库指标
- 稳定性指标
- 可扩展性指标
- 可靠性指标
下面将从如上这几个维度，分别从各自维度常见指标，以及指标含义、指标行业参考标准等方面进行介绍。
系统性能指标
系统性能指标，常见的可从如下几类进行参考：
- 响应时间
- 系统处理能力
- 吞吐量
- 并发用户数
- 错误率
响应时间
定义和解释： 响应时间，简称RT。是指系统对请求作出响应的时间，可以理解为是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。
在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒，由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。
行业参考标准： 不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
- 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
- 金融企业：1秒以下为佳，部分复杂业务3秒以下。
- 保险企业：3秒以下为佳。
- 制造业：5秒以下为佳。
- 时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。
- 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
- 金融企业：1秒以下为佳，部分复杂业务3秒以下。
- 保险企业：3秒以下为佳。
- 制造业：5秒以下为佳。
- 时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。
需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。
系统处理能力
定义和解释： 系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。
一般情况下，系统处理能力又用以下几个指标来度量：
- HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
- TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
- QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。
行业参考标准：对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。
- 金融行业：1000TPS~50000TPS，不包括互联网化的活动
- 保险行业：100TPS~100000TPS，不包括互联网化的活动
- 制造行业：10TPS~5000TPS
- 互联网电子商务：10000TPS~1000000TPS
- 互联网中型网站：1000TPS~50000TPS
- 互联网小型网站: 500TPS~10000TPS
吞吐量
定义和解释： 吞吐量是指系统在单位时间内处理请求的数量。对于单用户的系统，响应时间可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
而对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
并发用户数
定义和解释： 并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。
并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。
与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。
错误率
定义和解释： 错误率简称FR，指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
行业参考标准：
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%
资源性能指标
资源性能指标，常见的可从如下几类进行参考：
- CPU
- 内存
- 磁盘吐吞量
- 网络吐吞量
CPU
定义和解释： CPU又称为中央处理器，是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。
行业参考标准：
CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
- CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;
- CPU sys%小于或者等于30%;
- CPU wait%小于或者等于5%；
内存
定义和解释： 内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。
行业参考标准：
现在的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
磁盘吐吞量
定义和解释： 磁盘吞吐量简称为Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
行业参考标准：
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
网络吐吞量
定义和解释： 网络吞吐量简称为Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
行业参考标准： 网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
中间件指标
常用的中间件例如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比较合适。
数据库指标
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
| 一级指标 | 二级指标 | 单位 | 解释 |
|---|---|---|---|
| SQL | 耗时 | 微秒 | 执行SQL耗时 |
| 吞吐量 | QPS | 个 | 每秒查询次数 |
| 吞吐量 | TPS | 个 | 每秒事务次数 |
| 命中率 | Key Buffer命中率 | 百分之 | 索引缓冲区命中率 |
| 命中率 | InnoDB Buffer命中率 | 百分比 | InnoDB缓冲区命中率 |
| 命中率 | Query Cache命中率 | 百分比 | 查询缓存命中率 |
| 命中率 | Table Cache命中率 | 百分比 | 表缓存命中率数 |
| 命中率 | Thread Cache命中率 | 百分比 | 线程缓存命中率 |
| 锁 | 等待次数 | 次 | 锁等待次数 |
| 锁 | 等待时间 | 微秒 | 锁等待时间 |
行业参考标准：
- SQL耗时越小越好，一般情况下微秒级别。
- 命中率越高越好，一般情况下不能低于95%。
- 锁等待次数越低越好，等待时间越短越好。
稳定性指标
最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。
一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。
对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
参考标准：
- TPS曲线稳定，没有大幅度的波动。
- 各项资源指标没有泄露或异常情况。
可扩展性指标
定义和解释：是指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。
计算公式 为：（增加性能/原始性能）/（增加资源/原始资源）*100%。
扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
参考标准：
理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在70%以上。
可靠性指标
对于服务端性能测试，从系统可靠性指标度量分析时，常见从三类来入手：
- 双机热备
- 集群
- 备份和恢复
双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
- 节点切换是否成功及其消耗时间。
- 双机切换是否有业务中断。
- 节点回切是否成功及其耗时。
- 双机回切是否有业务中断。
- 节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
- 集群中某个节点出现故障时，系统是否有业务中断情况出现
- 在集群中新增一个节点时，是否需要重启系统
- 当故障节点恢复后，加入集群，是否需要重启系统
- 当故障节点恢复后，加入集群，系统是否有业务中断情况出现
- 节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
备份和恢复
本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
- 备份是否成功及其消耗时间。
- 备份是否使用脚本自动化完成。
- 恢复是否成功及其消耗时间。
- 恢复是否使用脚本自动化完成指标体系的运用原则。
- 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
- 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
- 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
- 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
- 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。
性能测试场景设计
场景分类
- 手工场景
手工场景可以为同一个组中的不同用户分配不同的脚本，负载生成器。
- 目标场景
面向目标场景，即首先的定义需要测试达到的目标，然后loadrunner会自动根据这一目标创建场景。
场景设计策略
- 快增长
使用场合：比如说秒杀功能。
问题： loadrunner场景中的加载方式：simultaneously，即同时加载。和Initialize中的
一次性初始化所有的vuser用户的选项，两者有什么区别吗？
- 慢增长
使用场合：单个场景，比如打开某个页面，接口，登录等操作。
- 用户数执行完场景停止场景
用户停止场景即用户执行完场景完后，退出当前的场景的操作。
问题： 一般情况来说，用户停止场景的方式，是与用户加载的方式一样适合还是一次性全部退出场景适合呢？
问题： 用户场景的执行时间：可以不可以这样理解，用户场景的整体执行时间等于：
用户加载时间+用户执行时间+用户退出场景的时间？
场景适用场合
- 单场景
例如：打开某个页面操作，用户登录等。
- 混合场景
混合场景，即多个业务组成的场景。比如BBS论坛发帖，有用户登录，发帖，回帖的业务，这些业务可以组成一个混合的场景，在运行场景时，可以指定多少vuser去执行某一个单个业务的操作。
问题： 在混合场景中，针对了某个单业务进行了检查点的设置，例如BBS论坛的发帖检查点，当虚拟用户数变多时，其整个发帖的事物响应时间明显变慢，是不是增加了检查点后，在多虚拟用户执行场景时，会影响到其事务的响应时间呢？或者说检查点不适合在混合场景中多次添加？
压力机
- 压力机定义
压力机顾名思义就是增加压力的机器，即负载机，在性能测试过程中，可以指定多个加压机对其进行加压。
- 添加负载机步骤
1、保证联合的机器上装了LRagent，并启用了。（状态栏会有一个小卫星）
2、本地系统的服务RPC服务开启，改为自动。
3、请从你的Controller的机子上登录要联合的机子。
4、关闭防火墙+杀毒+360等。拥有权限，必须保证负载机器在同一个网段内，保持网络可以相互通信。
参考资料
性能测试的内容到这里啦！如有需要了解软件测试相关的其他内容，可到「 [主页]」进行查看学习~
同时，有不理解或有误的地方也欢迎评论区留言大家一起吹牛聊天交流技术🤗。
- ✔️如果这篇文章对你有用，记得点个赞👍🏻加个关注支持我一下~
- ✔️我们下期见！👋👋👋
