性能测试各个指标之间关系

Posted 2023-03-04

参考技术A TPS

压力测试工具中的线程数和TPS并不会完全等于服务端的线程数和TPS，在具体的项目性能测试过程中，我们应该尽可能关注服务端能处理的请求数即关注服务端的TPS。

并发

建议做性能测试不要总说系统能支持多少并发，这个瞬时概念不能很好的衡量系统性能，那还是用TPS来的和谐。

并发数和TPS

有50个并发线程，每个线程都可以在1秒内完成100个事务，那么TPS=5000。

在线用户估算TPS

很多业务中，并发度都会低于5%，甚至低于1%。假设5%并发度，100w用户来计算：

TPS=100w x 5%=50000

根据TPS估算并发线程数

如果这时响应时间是 10ms，那显然并发线程数理论上是 50000TPS/(1000ms/10ms)=5000(响应时间是波动的所以是理论值)。

压测机器与线程数

运行压力测试工具的机器所能启动的线程数是与其硬件相关的，所以使用线程数一定要合理，并且把压测机器纳入压测的监控范围

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

从性能测试分析度量的角度，性能指标的维度如下：

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

接下来从各自维度常见指标及指标含义看看各个性能测试指标

一、系统性能指标

系统性能指标，常见的有如下几类：

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

1.1 响应时间

响应时间，简称RT
指系统对请求作出响应的时间，可以理解为用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程耗费的时间
直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间

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

1.2 系统处理能力

指系统在利用系统硬件平台和软件平台进行信息处理的能力
系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：

• 业务人员角度的一笔业务过程
• 系统角度的一次交易申请和响应过程

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

一般情况下，系统处理能力用以下几个指标来度量：

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

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

1.3 吞吐量

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

• 对于单用户的系统，响应时间可以很好地度量系统的性能
• 对于并发系统，通常需要用吞吐量作为性能指标

一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致

1.4 并发用户数

指在同一时刻内，登录系统并进行业务操作的用户数量

• 对于长连接系统来说最大并发用户数即是系统的并发接入能力
• 对于短连接系统而言最大并发用户数并不等于系统的并发接入能力
  短连接系统的并发用户数与系统架构、系统处理能力等各种情况相关

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

1.5 错误率

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

二、资源性能指标

资源性能指标，常见的有如下几类：

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

2.1 CPU

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

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

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

CPU的评估建议值：

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

2.2 内存

内存是与CPU进行沟通的桥梁
计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大

现在的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈
衡量系统内存是否有瓶颈主要靠SWAP(与虚拟内存交换)交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下

2.3 磁盘吐吞量

磁盘吞吐量简称为Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量

磁盘指标主要有：

• 每秒读写多少兆
• 磁盘繁忙率
• 磁盘队列数
• 平均服务时间
• 平均等待时间
• 空间利用率

其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%

2.4 网络吐吞量

网络吞吐量简称为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比较合适
• GC频率不能频繁，特别是FULL GC更不能频繁
  一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024M比较合适

四、数据库指标

常用的数据库例如ＭySQL指标主要包括：

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

具体指标如下：

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

指标的参考标准：

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

五、稳定性指标

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

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

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

参考标准：

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

六、可扩展性指标

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

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

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

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

七、可靠性指标

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

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

7.1 双机热备

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

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

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

7.2 集群

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

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

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

7.3 备份和恢复

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

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

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

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