【性能测试】常见的性能测试指标

系统性能指标如下：

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

响应时间，简称RT 指系统响应请求的时间，可以理解为用户从客户端启动请求，到客户端收到从服务器端返回的响应，整个过程需要时间 直观地说，该指标与人们对软件性能的主观感受非常一致，因为它完全记录了整个计算机系统处理请求的时间

响应时间的绝对值不能直接反映软件的性能。软件的性能实际上取决于用户对响应时间的接受程度

指系统在系统硬件平台和软件平台上处理信息的能力 通过对系统每秒可以处理的交易数量进行评估，对交易有两种理解：

• 从业务人员的角度来看，
• 交易申请和响应过程的系统角度

前者称为业务交易过程，后者称为业务，两个交易指标都可以评估应用系统的处理能力

一般来说，系统处理能力用以下指标来衡量：

• HPS(Hits Per Second)：每秒点击次数，单位为次/秒
• TPS(Transaction per Second)：系统每秒处理交易数，单位为笔/秒
• QPS(Query per Second)：系统每秒处理查询次数，单位为次/秒

在互联网业务中，如果有些业务有并且只有一个请求连接，那么TPS=QPS=HPS，一般情况下使用TPS用来衡量整个业务流程，QPS用来衡量接口查询的次数HPS表示单击服务器请求

指系统在单位时间内处理请求的数量

• 对于单用户系统，响应时间可以很好地衡量系统的性能
• 对于并发系统，并发系统的性能指标

指同时登录系统并操作业务的用户数量

• 对于长连接系统来说，最大并发用户数是系统的并发接入能力
• 对于短连接系统来说，最大并发用户数并不等于系统的并发接入能力 短连接系统的并发用户数与系统架构、系统处理能力等有关

与吞吐量相比，并发用户的数量是一个更直观但更普遍的性能指标。事实上，并发用户的数量是一个非常不准确的指标，因为不同的用户模式会导致不同的用户在单位时间发出不同数量的请求

错误率简称FR 指系统在负载下失败交易的概率

常见的资源性能指标

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

CPU它也被称为中央处理器，是一个超大的集成电路，是计算机计算的核心(Core)和控制核心(Control Unit)，该功能主要是解释计算机指令和处理计算机软件中的数据

CPU指标主要指的CPU利用率包括：

• 用户态(user)
• 系统态(sys)
• 等待态(wait)
• 空闲态(idle)

CPU评估建议值：

• 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，具体如下：

指标参考标准：

• 目前正在运行的线程数不得超过设定的最大值 一般来说，当系统性能良好时，线程数最小值设置为50，最大值设置为200
• 当前运行的JDBC连接数不得超过设定的最大值 一般情况下，系统性能较好，JDBC最小值设置50和最大值设置200更合适
• GC频率不能频繁，尤其是FULL GC更不能频繁 一般情况下，系统性能较好，JVM最小堆大小和最大堆大小分别设置1024M比较合适

M等常用数据库ySQL指标主要包括：

• 吞吐量
• 缓存命中率
• 连接数

具体指标如下：

指标的参考标准：

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

• 最短稳定时间 系统按照最大容量的80%或标准压力(系统的预期日常压力)情况下运行，能够稳定运行的最短时间

一般来说，对于正常工作日(8小时)运行的系统，至少应该能保证系统稳定运行8小时以上 对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上

如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险

参考标准：

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

指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系

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

扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好

参考标准： 理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在70%以上

对于服务端性能测试，从系统可靠性指标度量分析时，常见如下：

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

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

• 节点切换是否成功及其消耗时间
• 双机切换是否有业务中断
• 节点回切是否成功及其耗时
• 双机回切是否有业务中断
• 节点回切过程中的数据丢失量

在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况

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

• 集群中某个节点出现故障时，系统是否有业务中断情况出现
• 在集群中新增一个节点时，是否需要重启系统
• 当故障节点恢复后，加入集群，是否需要重启系统
• 当故障节点恢复后，加入集群，系统是否有业务中断情况出现
• 节点切换需要多长时间

在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况

验证系统的备份/恢复机制是否有效可靠，包括：

• 系统的备份和恢复
• 数据库的备份和恢复
• 应用的备份和恢复

备份和恢复的验证主要包括以下内容：

• 备份是否成功及其消耗时间
• 备份是否使用脚本自动化完成
• 恢复是否成功及其消耗时间
• 恢复是否使用脚本自动化完成