性能测试指标笔记
我们经常说要提升程序的性能，提升性能的方法有很多，评判的依据是某些指标朝着好的方向发展，站在服务端首先能想到的是 QPS、TPS、RT，前端页面最常见的指标是页面加载速度、首屏有限显示时间，同意数据库、中间件使用什么指标度量也有许多。
一、常见指标计算方式
不同计算方式对指标呈现影响很大，需要明确计算方式让指标准确呈现程序的现状，常见计算方式有。
- 平均值：易受极值影响，这种情况下呈现数据不客观。
- 最大值、最小值
- 中位数：多数情况下比“平均值”客观
- 分位值：求一组递增序列某个位置的值，如果有 100 个数（1..100)，求 25 分位就是 25，50 分位就是 50。通常我们所说的求某个指标的 P50、P90，意思是取这个指标的 50 分位值和 90 分位值 1。
二、服务端指标
2.1 响应时间
RT（Response Time，响应时间），这是 Web 程序最常用的指标，指客户端请求发起到从服务端接收到响应结果这个过程的耗时。
2.2 处理能力
定义：系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。可以理解为一次业务处理过程或者一个（读或写）的请求-响应过程。
度量指标：
- TPS（Transaction Per Second）：系统每秒处理含事务操作的数量，特指含有更新或插入数据的请求-响应。
- QPS（Query Per Second）：系统每秒处理查询数量。
- HPS（Hits Per Second）：每秒点击次数。
一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器单击请求。
2.3 并发用户
并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。例如系统吞吐能力很强，加上短连接一般都有连接复用，往往并发用户数大于系统的并发接入连接数。
一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。
2.4 失败率
错误率指系统在负载下，业务处理失败的概率。失败率 = （失败数/总数）* 100%，在稳定性较好的系统中失败通常是由超时引起的。
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于 99.4%。
三、系统资源指标
3.1 CPU
CPU（Central Processing Unit）, 相关主要指标有：
- CPU 使用率
- CPU 利用率
二者有些细微差别需要注意，使用率标识 CPU 的繁忙程度，CPU 只要因为作业被占用（计算数据或期间因资源占用等因素停顿）就算 CPU 繁忙。但是 CPU 繁忙（使用率指标高）并不代表利用率高，而利用率就是除去计算期间停顿得出的指标，通常可以用周期内流水线处理的指令数作为衡量 2。
另外还应该关注的用户态（user）、系统态（sys）、等待（wait）、空闲（idle）的时间。
3.2 内存
内存是构成计算机中重要组件，运行中的绝大多数数据都在内存中，因此内存的性能对计算机影响非常大。现在操作系统为了最大限度利用内存，增加了虚拟内存技术，因此内存利用率 100% 并不代表内存有瓶颈，衡量系统内还有 SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP 交换空间利用率要低于 70%，太多的交换将会引起系统性能低下。
3.3 磁盘吞吐
磁盘吞吐指单位时间内通过磁盘的数据量。
磁盘的主要指标有：
- read&write MB/s - 每分钟读写兆字节
- 磁盘繁忙率
- 磁盘队列数
- 平均服务时间
- 平均等待时间
- 空间利用率
3.4 网络吞吐量
网络单位时间内通过数据量。单位通常是 Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备，一般情况下不能超过设备或链路最大传输能力的 70%。
四、中间件指标
基于 Java 技术栈常用的中间价包括 Tomcat、MQ、Weblogic 等，主要指标包括 GC、ThreadPool、JDBC 等。
| 一级指标 | 二级指标 | 单位 | 说明 |
|---|---|---|---|
| GC/JVM | GC 频率 | times/s | Java 虚拟机局部垃圾回收频率 |
| Full GC 频率 | times/hour | Java 虚拟机对整个堆进行垃圾回收的频次 | |
| Full GC 平均时长 | s | - | |
| Full GC 最小时长 | s | - | |
| Full GC 最大时长 | s | - | |
| 堆使用率 | % | 程序资源预热后，已使用的堆空间占比 | |
| ThreadPool | 活跃线程数 | 个 | - |
| 请求线程数 | 个 | 处于排队的用户请求数 | |
| JDBC | 活跃连接数 | 个 | JDBC 活动连接数 |
实践：
- 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置 50 和最大值设置 200 比较合适。
- 当前运行的 JDBC 连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC 最小值设置 50 和最大值设置 200 比较合适。
- GC 频率不能频繁，特别是 Full GC 更不能频繁，一般情况下系统性能较好的情况下，JVM 最小堆大小和最大堆大小分别设置 1024M 比较合适。
| 一级指标 | 二级指标 | 单位 | 解释 |
|---|---|---|---|
| SQL | 耗时 | 微秒 | 执行 SQL 耗时 |
| 吞吐量 | QPS | 个 | 每秒查询次数 |
| TPS | 个 | 每秒事务次数 | |
| 命中率 | Key Buffer 命中率 | % | 索引缓冲区命中率 |
| InnoDB Buffer 命中率 | % | InnoDB 缓冲区命中率 | |
| Query Cache 命中率 | % | 查询缓存命中率 | |
| Table Cache 命中率 | % | 表缓存命中率 | |
| Thread Cache 命中率 | % | 线程缓存命中率 | |
| 锁 | 等待次数 | 次 | 锁等待次数 |
| 等待时间 | 微秒 | 锁等待时间 |
实践：
- SQL 耗时越小越好，一般情况下微秒级别。
- 命中率越高越好，一般情况下不能低于 95%。
- 锁等待次数越低越好，等待时间越短越好。
五、前端指标
前端指标主要包括页面渲染时间和网络请求花费时间。
| 一级指标 | 二级指标 | 单位 | 解释 |
|---|---|---|---|
| 页面展示 | 首次显示时间 | ms | 在浏览器地址栏输入 URL 按回车到用户看到网页的第一个视觉标志为止。 |
| OnLoad 事件时间 | ms | 浏览器触发 onLoad 事件的时间，当原始文档和所有引用的内容完全下载后才会触发这个事件。 | |
| 完全载入的时间 | ms | 所有 onLoad JavaScript 处理程序执行完毕，所有动态的或延迟加载的内容都通过这些处理程序触发的时间。 | |
| 页面数量 | 页面大小 | KB | 整个页面大小。 |
| 请求数量 | 次 | 从网站下载资源时所有网络请求的总数，尽量少。 | |
| 网络 | DNS 时间 | ms | DNS 查找时间。 |
| 连接时间 | ms | 连接时间就是浏览器与 Web 服务器建立 TCP/IP 连接的时间。 | |
| 服务器时间 | ms | 服务器处理时间。 | |
| 传输时间 | ms | 内容传输所用时间。 | |
| 等待时间 | ms | 等待某个资源释放的时间。 |
六、稳定性指标
定义及解释：
最短稳定时间：系统按照最大容量的 80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。 一般来说，对于正常工作日（8 小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于 7×24 运行的系统，至少应该能够保证系统稳定运行 24 小时以上。 如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
标准：
- TPS 曲线稳定，没有大幅度的波动。
- 各项资源指标没有泄露或异常情况。
七、批量处理指标
定义及解释：
指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。 关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。 长时间批量处理将会对联机在线实时交易产生重大的性能影响。
标准：
- 在数据量很大的情况下，批处理时间窗口时间越短越好。
- 不能影响实时交易系统性能。
八、可扩展性指标
定义及解释：
指应用软件或操作系统以集群方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。 扩展能力应通过多轮测试获得扩展指标的变化趋势。 一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
标准：
- 理想的扩展能力是资源增加几倍，性能就提升几倍。
- 扩展能力至少在 70%以上。
九、可靠性指标
9.1 双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
- 节点切换是否成功及其消耗时间。
- 双机切换是否有业务中断。
- 节点回切是否成功及其耗时
- 双机回切是否有业务中断。
- 节点回切过程中的数据丢失量。在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
9.2 集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
- 集群中某个节点出现故障时，系统是否有业务中断情况出现。
- 在集群中新增一个节点时，是否需要重启系统。
- 当故障节点恢复后，加入集群，是否需要重启系统。
- 当故障节点恢复后，加入集群，系统是否有业务中断情况出现。
- 节点切换需要多长时间。在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
9.3 备份和恢复
这些标为了验证系统的备份、恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
- 备份是否成功及其消耗时间。
- 备份是否使用脚本自动化完成。
- 恢复是否成功及其消耗时间。
- 恢复是否使用脚本自动化完成指标体系的运用原则。
- 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
- 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
- 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
- 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
- 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。