性能专题:一文搞懂性能测试常见指标

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 性能专题:一文搞懂性能测试常见指标

1. 前言


上周,对性能测试系列专题,在公号内发表了第一篇介绍:【性能系列连载一】开篇:性能测试不可不知的“干货”,但反响貌似并不太好,但既然此前已答应了部分读者要连载分享性能这块的知识,含着泪也得继续写。


性能测试的基础:就是在确保功能实现正确的前提下,通过合适的性能测试加压方式和策略,并收集考察服务端应用程序的各项性能指标,以及服务器硬件资源的使用情况,来评估是否存在性能问题隐患。


那今天作为性能测试系列的第二篇,主要会为大家介绍在服务端性能测试中,常见的性能指标有哪些。


2. 性能指标分类


从性能测试分析度量的度角来看,可以从如下几个维度来收集考察各项性能指标:

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


下面将从如上这几个维度,分别从各自维度常见指标,以及指标含义、指标行业参考标准等方面进行介绍。

3. 系统性能指标


系统性能指标,常见的可从如下几类进行参考:

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

3.1 响应时间

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


在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量,单位一般为秒或毫秒,由于一个系统通常会提供许多功能,而不同功能的处理逻辑也千差万别,因而不同功能的响应时间也不尽相同,甚至同一功能在不同输入数据的情况下响应时间也不相同。所以,在讨论一个系统的响应时间时,通常是指该系统所有功能的平均时间或者所有功能的最大响应时间


行业参考标准:

不同行业不同业务可接受的响应时间是不同的,一般情况,对于在线实时交易:

  • 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。
  • 金融企业:1秒以下为佳,部分复杂业务3秒以下。
  • 保险企业:3秒以下为佳。
  • 制造业:5秒以下为佳。
  • 时间窗口:不同数据量结果是不一样的,大数据量的情况下,2小时内完成。


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

3.2 系统处理能力

定义和解释:系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价,交易有两种理解:一是业务人员角度的一笔业务过程;二是系统角度的一次交易申请和响应过程。前者称为业务交易过程,后者称为事务。两种交易指标都可以评价应用系统的处理能力。


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

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


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


行业参考标准:

无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下:

  • 金融行业:1000TPS~50000TPS,不包括互联网化的活动
  • 保险行业:100TPS~100000TPS,不包括互联网化的活动
  • 制造行业:10TPS~5000TPS
  • 互联网电子商务:10000TPS~1000000TPS
  • 互联网中型网站:1000TPS~50000TPS
  • 互联网小型网站: 500TPS~10000TPS

3.3 吞吐量

定义和解释:吞吐量是指系统在单位时间内处理请求的数量。

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

而对于一个多用户的系统,如果只有一个用户使用时系统的平均响应时间是t,当有你n个用户使用时,每个用户看到的响应时间通常并不是n×t,而往往比n×t小很多(当然,在某些特殊情况下也可能比n×t大,甚至大很多)。一般而言,吞吐量是一个比较通用的指标,两个具有不同用户数和用户使用模式的系统,如果其最大吞吐量基本一致,则可以判断两个系统的处理能力基本一致。

3.4 并发用户数

定义和解释:并发用户数指在同一时刻内,登录系统并进行业务操作的用户数量。


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


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

3.5  错误率

定义和解释:错误率简称FR,指系统在负载情况下,失败交易的概率。错误率=(失败交易数/交易总数)*100%。


行业参考标准:

不同系统对错误率的要求不同,但一般不超出千分之六,即成功率不低于99.4%


4. 资源性能指标


资源性能指标,常见的可从如下几类进行参考:

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

4.1  CPU

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


行业参考标准:

CPU指标主要指的CPU利用率,包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。

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


4.2  内存

定义和解释:内存是计算机中重要的部件之一,它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的,因此内存的性能对计算机的影响非常大。


行业参考标准:

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

4.3  磁盘吐吞量

定义和解释:磁盘吞吐量简称为Disk Throughput,是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。


行业参考标准:

磁盘指标主要有每秒读写多少兆,磁盘繁忙率,磁盘队列数,平均服务时间,平均等待时间,空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据,一般情况下,磁盘繁忙率要低于70%。

4.4  网络吐吞量

定义和解释:网络吞吐量简称为Network Throughput,是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时,则需要考虑升级网络设备。


行业参考标准:

网络吞吐量指标主要有每秒有多少兆流量进出,一般情况下不能超过设备或链路最大传输能力的70%。

5. 中间件指标


常用的中间件例如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比较合适。


6. 数据库指标


常用的数据库例如MySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等,具体如下:

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


行业参考标准:

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


7. 稳定性指标


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


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


对于7*24运行的系统,至少应该能够保证系统稳定运行24小时以上。如果系统不能稳定的运行,上线后,随着业务量的增长和长时间运行,将会出现性能下降甚至崩溃的风险。


参考标准:

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


8. 可扩展性指标


定义和解释:是指应用软件或操作系统以群集方式部署,增加的硬件资源与增加的处理能力之间的关系。


计算公式:(增加性能/原始性能)/(增加资源/原始资源)*100%。


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


参考标准:

理想的扩展能力是资源增加几倍,性能就提升几倍。扩展能力至少在70%以上。


9. 可靠性指标


对于服务端性能测试,从系统可靠性指标度量分析时,常见从三类来入手:

  • 双机热备

  • 集群
  • 备份和恢复

9.1 双机热备

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


  • 节点切换是否成功及其消耗时间。
  • 双机切换是否有业务中断。
  • 节点回切是否成功及其耗时。
  • 双机回切是否有业务中断。
  • 节点回切过程中的数据丢失量在进行双机切换的同时,使用压力发生工具模拟实际业务发生情况,对应用保持一定的性能压力,保证测试结果符合生产实际情况。

9.2 集群

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


  • 集群中某个节点出现故障时,系统是否有业务中断情况出现
  • 在集群中新增一个节点时,是否需要重启系统
  • 当故障节点恢复后,加入集群,是否需要重启系统
  • 当故障节点恢复后,加入集群,系统是否有业务中断情况出现
  • 节点切换需要多长时间在验证集群可靠性的同时,需根据具体情况使用压力工具模拟实际业务发生相关情况,对应用保持一定的性能压力,确保测试结果符合生产实际情况。


9.3 备份和恢复

本指标为了验证系统的备份/恢复机制是否有效可靠,包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复,包括以下测试内容:


  • 备份是否成功及其消耗时间。
  • 备份是否使用脚本自动化完成。
  • 恢复是否成功及其消耗时间。
  • 恢复是否使用脚本自动化完成指标体系的运用原则。
  • 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样,测试目的不一样,测试需求也不一样,考察的指标项也有很大差别。
  • 部分系统涉及额外的前端用户接入能力的,需要考察用户接入并发能力指标。
  • 对于批量处理过程的性能验证,主要考虑批量处理效率并估算批量处理时间窗口。
  • 如测试目标涉及到系统性能容量,测试需求中应根据相关指标项的定义,明确描述性能指标需求。
  • 测试指标获取后,需说明相关的前提条件(如在多少的业务量、系统资源情况等)。


其中上述提到的【可扩展指标】和【可靠性指标】,大多数公司在开展性能测试的时候很少会涉及到这些测试点,但这些点从产品整体性能和质量角度来讲,又是不得不关注的一些重点,算是给大家提供一些测试思路。


相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
1月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
2月前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
113 2
|
1月前
|
监控 测试技术 PHP
性能和压力测试
【10月更文挑战第10天】性能和压力测试
113 60
|
1月前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
67 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
|
2月前
|
缓存 Java 测试技术
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
使用JMeter对项目各个接口进行压力测试,并对前端进行动静分离优化,优化三级分类查询接口的性能
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
|
1月前
|
测试技术 PHP 开发工具
php性能监测模块XHProf安装与测试
【10月更文挑战第13天】php性能监测模块XHProf安装与测试
31 0
|
2月前
|
敏捷开发 安全 测试技术
软件测试的艺术:确保质量与性能的平衡之道
【9月更文挑战第24天】在软件开发的海洋中,测试是导航灯塔,指引着项目安全抵达质量的彼岸。本文将深入探讨软件测试的核心原则、方法论以及如何通过精心设计的测试策略来保障产品的可靠性和性能。我们将从测试的基础知识出发,逐步深入到高级测试技巧,最终展示如何通过实际案例来应用这些知识以确保软件的成功交付。
|
2月前
|
测试技术 Python
软件测试的艺术:确保质量与性能
【9月更文挑战第19天】在数字化时代,软件已成为我们生活的一部分。然而,随着软件复杂性的增加,如何确保其质量和性能成为了一个挑战。本文将探讨软件测试的重要性,介绍常见的测试类型和策略,并提供实用的代码示例来帮助读者更好地理解和应用这些测试方法。无论你是开发人员、测试工程师还是项目管理者,这篇文章都将为你提供有价值的见解和技巧。
|
2月前
|
存储 Java 关系型数据库
“代码界的魔法师:揭秘Micronaut框架下如何用测试驱动开发将简单图书管理系统变成性能怪兽!
【9月更文挑战第6天】Micronaut框架凭借其轻量级和高性能特性,在Java应用开发中备受青睐。本文通过一个图书管理系统的案例,介绍了在Micronaut下从单元测试到集成测试的全流程。首先,我们使用`@MicronautTest`注解编写了一个简单的`BookService`单元测试,验证添加图书功能;接着,通过集成测试验证了`BookService`与数据库的交互。整个过程展示了Micronaut强大的依赖注入和测试支持,使测试编写变得更加高效和简单。
76 4
|
3月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
下一篇
无影云桌面