系统性能指标
1.1 交易响应时间
1.1.1 定义及解释
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒,如果利用PTS发起侧优势+生产环境则无限接近于真实环境的用户体验时间了。平均响应时间：指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。
1.1.2 简称
Response Time: RT
1.1.3 参考标准
不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
- 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
- 金融企业：1秒以下为佳，部分复杂业务3秒以下。
- 保险企业：3秒以下为佳。
- 制造业：5秒以下为佳。
对于批量交易：
- 时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。
1.2 系统处理能力
1.2.1 定义及解释
系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。
1.2.2 简称
一般情况下，用以下几个指标来度量：
- HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
- TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
- QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。
1.2.3 标准
无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
- 金融行业：1000TPS~50000TPS，不包括互联网化的活动
- 保险行业：100TPS~100000TPS，不包括互联网化的活动
- 制造行业：10TPS~5000TPS
- 互联网电子商务：10000TPS~1000000TPS
- 互联网中型网站：1000TPS~50000TPS
- 互联网小型网站: 500TPS~10000TPS
1.3 并发用户数
1.3.1 定义及解释
并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。比如系统吞吐能力很强，加上短连接一般都有连接复用，往往并发用户数大于系统的并发接入连接数。所以对于大部分短连接类型的系统，吞吐量模式（RPS模式,Request Per Second）比较适合，也是阿里的最佳实践，PTS支持RPS模式的压测，吞吐量的压测构建和衡量一步到位。在测试中，采用虚拟用户来模拟现实中用户进行业务操作。
1.3.2 简称
Virtual User: VU
1.3.3 标准
一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。
1.4 错误率
1.4.1 定义及解释
错误率指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。
1.4.2 简称
Failure Ratio: FR
1.4.3 标准
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%
2 资源指标
2.1 CPU
2.1.1 定义及解释
中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load: 系统正在干活的多少的度量，队列长度。系统平均负载。
2.1.2 简称
Central Processing Unit：CPU
2.1.3 标准
CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。单核CPU也需遵循上述指标要求。CPU Load要小于CPU 核数。
2.2 Memory
2.2.1 定义及解释
内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。
2.2.2 简称
Memory就是内存的简称。
2.2.3 标准
现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
2.3 磁盘吞吐量
2.3.1 定义及解释
磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
2.3.2 简称
Disk Throughput.
2.3.3 标准
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
2.4 网络吞吐量
2.4.1 定义及解释
网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
2.4.2 简称
Network Throughput
2.4.3 标准
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
2.5 内核参数
操作系统内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可，具体如下:
|
一级指标
|
二级指标
|
单位
|
解释
|
备注
|
|---|---|---|---|---|
| 内核参数 | Maxuprc | 个 | 限制每个用户的用户进程的最大数量 | |
| Max_thread_proc | 个 | 定义每个进程允许的最大线程数量 | ||
| Filecache_max | 字节 | 最大可用于cache file I/O的物理内存 | ||
| Ninode | 个 | 内存中 HFS 文件系统打开 i 节点的最大数量 | ||
| Nkthread | 个 | 限制允许同时运行的线程数量 | ||
| Nproc | 个 | 限制允许同时运行的进程数量 | ||
| Nstrpty | 个 | 基于 STREAMS 的伪终端 (pts) 的最大数量 | ||
| Maxdsiz | 字节 | 任何用户进程的数据段的最大大小（以字节为单位） | ||
| maxdsiz_64bit | 字节 | 任何用户进程的数据段的最大大小（以字节为单位） | ||
| maxfiles_lim | 个 | 每个进程的文件描述符的最大数目硬限制 | ||
| maxssiz_64bit | 字节 | 任何用户进程的堆栈的最大大小 | ||
| Maxtsiz | 字节 | 任一用户进程的文本段的最大大小 | ||
| nflocks | 个 | 文件锁的最大数量 | ||
| maxtsiz_64bit | 字节 | 任一用户进程的文本段的最大大小 | ||
| msgmni | 个 | 系统级 System V IPC 消息队列 (ID) 所允许的最大数量 | ||
| msgtql | 个 | 系统中任意时间的最大 System V IPC 消息数 | ||
| npty | 个 | BSD 伪终端 (pty) 的最大数量 | ||
| nstrtel | 个 | 指定内核可支持传入 telnet 会话的 telnet 设备文件的数量 | ||
| nswapdev | 个 | 可用于交换的设备的最大数量 | ||
| nswapfs | 个 | 可用于交换的文件系统的最大数量 | ||
| semmni | 个 | System V IPC 系统级信号量标识符的数量 | ||
| semmns | 个 | System V 系统级信号量的数量 | ||
| shmmax | 字节 | System V 共享内存段的最大大小 | ||
| shmmni | 个 | 系统中 System V 共享内存段标识符的数量 | ||
| shmseg | 个 | 每个进程 System V 共享内存段的最大数量 |
3 中间件指标
3.1 定义及解释
常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC,具体如下：
| 一级指标 | 二级指标 | 单位 | 解释 | 备注 |
|---|---|---|---|---|
| GC | GC频率 | 每秒多少次 | java虚拟机垃圾部分回收频率 | |
| Full GC频率 | 每小时多少次 | java虚拟机垃圾完全回收频率 | ||
| Full GC平均时长 | 秒 | 用于垃圾完全回收的平均时长 | ||
| Full GC最大时长 | 秒 | 用于垃圾完全回收的最大时长 | ||
| 堆使用率 | 百分比 | 堆使用率 | ||
| ThreadPool | Active Thread Count | 个 | 活动的线程数 | |
| Pending User Request | 个 | 处于排队的用户请求个数 | ||
| JDBC | JDBC Active Connection | 个 | JDBC活动连接数 |
3.2 标准
- 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。
- 当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。
- ＧＣ频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适。
4 数据库指标
4.1 定义及解释
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
| 一级指标 | 二级指标 | 单位 | 解释 | 备注 |
|---|---|---|---|---|
| SQL | 耗时 | 微秒 | 执行SQL耗时 | |
| 吞吐量 | QPS | 个 | 每秒查询次数 | |
| TPS | 个 | 每秒事务次数 | ||
| 命中率 | Key Buffer命中率 | 百分之 | 索引缓冲区命中率 | |
| InnoDB Buffer命中率 | 百分之 | InnoDB缓冲区命中率 | ||
| Query Cache命中率 | 百分之 | 查询缓存命中率 | ||
| Table Cache命中率 | 百分之 | 表缓存命中率 | ||
| Thread Cache命中率 | 百分之 | 线程缓存命中率 | ||
| 锁 | 等待次数 | 次 | 锁等待次数 | |
| 等待时间 | 微秒 | 锁等待时间 |
4.2 标准
- SQL耗时越小越好，一般情况下微秒级别。
- 命中率越高越好，一般情况下不能低于95%。
- 锁等待次数越低越好，等待时间越短越好。
5 前端指标
5.1 定义及解释
前端指标主要包括页面展示和网络所花的时间，具体如下：
| 一级指标 | 二级指标 | 单位 | 解释 | 备注 |
|---|---|---|---|---|
| 页面展示 | 首次显示时间 | 毫秒 | 在浏览器地址栏输入URL按回车到用户看到网页的第一个视觉标志为止 | |
| OnLoad事件时间 | 毫秒 | 浏览器触发onLoad事件的时间，当原始文档和所有引用的内容完全下载后才会触发这个事件 | ||
| 完全载入的时间 | 毫秒 | 所有onLoad JavaScript 处理程序执行完毕，所有动态的或延迟加载的内容都通过这些处理程序触发的时间 | ||
| 页面数量 | 页面大小 | KB | 整个页面大小 | |
| 请求数量 | 次 | 从网站下载资源时所有网络请求的总数，尽量少 | ||
| 网络 | DNS时间 | 毫秒 | DNS查找时间 | |
| 连接时间 | 毫秒 | 连接时间就是浏览器与Web服务器建立TCP/IP连接的时间 | ||
| 服务器时间 | 毫秒 | 服务器处理时间 | ||
| 传输时间 | 毫秒 | 内容传输所用时间 | ||
| 等待时间 | 毫秒 | 等待某个资源释放的时间 |
5.2 标准
- 页面要尽可能小及压缩。
- 页面展示和花费时间越短越好。
6 稳定性指标
6.1 定义及解释
最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
6.2 标准
- TPS曲线稳定，没有大幅度的波动。
- 各项资源指标没有泄露或异常情况。
7 批量处理指标
7.1 定义及解释
指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。长时间批量处理将会对联机在线实时交易产生重大的性能影响。
7.2 标准
- 在数据量很大的情况下，批处理时间窗口时间越短越好。
- 不能影响实时交易系统性能。
8 可扩展性指标
8.1 定义及解释
指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
8.2 标准
- 理想的扩展能力是资源增加几倍，性能就提升几倍。
- 扩展能力至少在70%以上。
9 可靠性指标
9.1 双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
- 节点切换是否成功及其消耗时间
- 双机切换是否有业务中断
- 节点回切是否成功及其耗时
- 双机回切是否有业务中断
- 节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
9.2 集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
- 集群中某个节点出现故障时，系统是否有业务中断情况出现
- 在集群中新增一个节点时，是否需要重启系统
- 当故障节点恢复后，加入集群，是否需要重启系统
- 当故障节点恢复后，加入集群，系统是否有业务中断情况出现
- 节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
9.3 备份和恢复
本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
- 备份是否成功及其消耗时间
- 备份是否使用脚本自动化完成
- 恢复是否成功及其消耗时间
- 恢复是否使用脚本自动化完成指标体系的运用原则
- 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
- 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
- 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
- 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
- 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。