性能专题:一文搞懂,性能测试指标评估方法

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 更多测试开发技术干货,请关注公众号:【测试开发技术】往期性能专题:开篇:性能测试不可不知的“干货”性能专题:一文搞懂性能测试常见指标阅读全文需8.5分钟。1. 前言在上一篇文章性能专题:一文搞懂性能测试常见指标中,已经介绍了,在开展性能测试时,各个维度的常见性能指标项有哪些。

更多测试开发技术干货,请关注公众号:【测试开发技术】

往期性能专题:

开篇:性能测试不可不知的“干货”

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

阅读全文需8.5分钟。

1. 前言

在上一篇文章性能专题:一文搞懂性能测试常见指标中,已经介绍了,在开展性能测试时,各个维度的常见性能指标项有哪些。

而本文将继续介绍,对于软件性能而言,有哪些指标是需要重点关注的,并且这些重点关注的指标又是如何来评估和计算的。

2. 软件性能的关注点

对一个软件做性能测试时,一般需要关注哪些性能项呢

换个角度来思考,我们在软件设计、部署、使用、维护中一共有哪些角色的参与,然后再考虑这些角色各自关注的性能点是什么?

首先,开发软件的目的是为了让用户使用,我们先站在用户的角度分析一下,用户会关注哪些性能呢

对于用户来说,当点击一个按钮、链接或发出一条指令开始,到系统把结果以用户感知的形式展现出来为止,这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间,当响应时间较小时,用户体验是很好的。当然用户体验的响应时间包括个人主观因素和客观响应时间,在设计软件时,我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如:用户在大数据量查询时,我们可以将先提取出来的数据展示给用户,在用户看的过程中继续进行数据检索,这时用户并不知道我们后台在做什么。

因此,用户关注的是用户操作后软件的响应时间。

其次,站在管理员或运维的角度考虑,他们一般关注的性能项有什么,通常来说,包括但不限如下一些指标项:

  • 响应时间
  • 服务器资源使用情况是否合理
  • 应用服务器和数据库资源使用是否合理
  • 系统最多支持多少用户访问、系统最大业务处理量是多少
  • 系统性能可能存在的瓶颈在哪里
  • 更换哪些设备可以提高性能
  • 系统能否支持7×24小时的业务访问

再者,站在开发(设计)人员角度去考虑,影响性能的因素,常见有如下一些。

  • 架构设计是否合理
  • 数据库设计是否合理
  • 代码是否存在性能方面的问题
  • 系统中是否有不合理的内存使用方式
  • 系统中是否存在不合理的线程同步方式
  • 系统中是否存在不合理的资源竞争

3. 衡量服务性能的关键指标及评估方法

在如此多的性能指标项中,最为重要的又有哪些?或者是说在衡量服务性能指标时,最常关注的几项性能指标有哪几个:QPS(TPS)、并发数、响应时间。

  • QPS(TPS):每秒钟处理request/事务的数量。
  • 并发用户数: 系统同时处理的request/事务的用户数量。
  • 响应时间(Response Time,RT): 可以理解为服务器处理响应的耗时,一般取平均响应时间。

下面将对QPS(TPS)、并发数、响应时间几项最主要的指标评估方法进行介绍,别急,且往下看。

3.1 并发用户数

  1. 提及并发用户数,如何理解什么才算是有效的并发用户

并发用户:指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User)。

需要注意的是,并发用户跟注册用户、在线用户有很大差别的,并发用户一定会对服务器产生压力的,而在线用户只是 ”挂” 在系统上,对服务器不产生压力,注册用户一般指的是数据库中存在的用户。

并发用户这些用户的最大特征是和服务器会产生交互,这种交互既可以是单向的传输数据,也可以是双向的传送数据。

2.并发用户数常见的评估方法

对于已有系统来说,评估并发用户数,可以从如下几个方面去做数据参考。

    1. 系统用户数
    1. 在线用户数
    1. 并发用户数

一般来说,可选取高峰时刻,在一定时间内使用系统的人数,这些人数可认为是在线用户数,而并发用户数可以取其中8%~15%的比例基数,例如在1个小时内,使用系统的在线用户数为10万,那么取8%~15%(即8000~1.5万)作为并发用户数就基本足够了。

当然,网上也流行另一种并发用户数评估计算方式(可供参考)

它是由几项因素来决定的:

登录系统的用户数量(n),可以理解为平均每天访问用户数。
用户从登录系统到退出系统的时间间隔(L),可以理解为一天内用户从登录到退出系统的时间间隔。
被考察的时间长度(T),可以理解为一天内有多长时间有用户访问系统

利用经验公式估算系统的平均并发用户数和峰值数据,方法可供参考(并不一定准确):

平均并发用户数为:

C = n*L/T

并发用户数峰值:

C‘ = C + 3*√C

其中√为根号

例如:某系统A,有3000个用户,平均每天大概有400个用户要访问该系统,对于一个典型用户来说,一天之内用户从登陆到退出的平均时间为4小时,而在一天之内,用户只有在8小时之内会使用该系统。那么,

平均并发用户数为:C = 400*4/8 = 200

并发用户数峰值为:C1 = 200 + 3*√200 = 243

对于新系统来说,如果没有历史数据作参考,建议通过业务部门进行评估。

3.2 响应时间

作为一个用户你可以对吞吐量(QPS、TPS)、并发用户数这些毫不关心,但响应时间却是用户感受系统性能的主要体现。从用户角度来说,软件性能就是软件对用户操作的响应时间。说得更明确一点,对用户来说,当用户单击一个按钮,发出一条指令或在web页面上单击一个链接,从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来,这个过程所消耗的时间就是用户对软件性能的直观印象。

响应时间既然对用户体验如此重要,那这个时间又是如何评估计算出来的呢?

用一个公式来表示:

响应时间=网络传输时间(请求)+服务器处理时间(一层或是多层)+网络传输时间(响应)+页面前段解析时间

更具体来讲:

响应时间=呈现时间+网络传输时间+系统处理时间

1. 呈现时间

呈现时间主要是指前端的响应时间,这部分时间主要取决于客户端而非服务端。当然,这个呈现时间也不能全怪罪客户端身上!它还和承载它的操作系统有关,以及电脑硬件比如cpu 、内存有关。

2. 网络传输时间

千万不要忽视数据传输时间。试想一下,如果你要寄信给你一个远方的朋友,你想是什么影响你将信息传递给远方的朋友?不是你写信的过程(如果你写的信不像书一样厚的话),也不是你朋友读信的过程,而是送信的过程。

你的带宽是多少?有没有考虑网络延迟? 互联网是个网,就是算是相同的起点与终点,它有可能走的不同的路线。

这也是为什么我们在一般做性能测试时,一般要强调要在局域网中进行

3. 系统处理时间

在进行性能测试时,呈现时间和数据传输时间通常都是我们很难控制的,用户使用的电脑千差万别,用户的网络状况也是千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短。

如果我们对系统处理进行分解的话,它又是一个非常庞大与复杂的过程。包括了语言、语言框架、中间件,数据库、系统架构以及服务器系统等。

现在的测试工具一般都屏蔽呈现过程,只是模拟多用户并发请求,计算用户得到响应的时间,也不会将服务器的每个响应都向客户端呈现。

对于数据传输的问题,这也是我要强调的性能测试要在局域网中进行,在局域网中一般不会受到数据带宽的限制。所以,可以对数据的传输时间忽略不计。

关于响应时间,要特别说明的一点是,对客户来说,该值是否能够被接受是带有一定的用户主观色彩,也就是说,响应时间的“长”和“短”没有绝对的区别。

在互联网行业对于用户响应时间,有一个普遍的标准:2/5/10秒原则。也就是说,在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验,在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应,那么大多用户会认为这次请求是失败的。这里我们还要考虑一个使用频率的因素。如果一个功能,一个月才用上一次,并且要求返回的结果也并非实时的,那么即便慢一些,对于用户来讲,也是可接受的。

3.3 系统吐吞量(QPSTPS)
系统吞吐量指单位时间内系统处理用户的请求数。从业务角度看,吞吐量可以用:请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量,从网络角度看,吞吐量可以用:字节/秒来衡量

对于交互式应用来说,吞吐量指标反映的是服务器承受的压力,他能够说明系统的负载能力。以不同方式表达的吞吐量可以说明不同层次的问题,例如,以字节数/秒方式可以表示主要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈;已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

QPS:全名 Queries Per Second,意思是“每秒查询率”,是一台服务器每秒能够响应的查询次数,简单的说,QPS = req/sec = 请求数/秒。比如执行了select操作,相应的QPS就会增加,它代表的是服务器的机器的性能最大吞吐能力。

计算QPS的常用公式:

QPS(TPS)= 并发数/平均响应时间

另外,关于峰值QPS计算方式,一般也可参照2/8原则(供参考,并非一定):

原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间

公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

问:每天300w PV 的在单台机器上,这台机器需要多少QPS?

答:( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

TPS即 Transactions Per Second 的缩写,指每秒处理的事务数量。一个事务是指一个客户机向服务器发送请求然后服务器做出回应的过程。

TPS 的过程包括:客户端请求服务端、服务端内部处理、服务端返回客户端

关于TPS的获取评估方式,对于已有系统来说:可选取高峰时刻,在一定时间内(如3-10分钟),获取系统总业务量,计算单位时间(秒)内完成的笔数,乘以2-5倍作为峰值的TPS,例如峰值3分钟内处理订单18万笔,平均TPS是1000,峰值TPS可以是2000-5000。

对于新系统来说,因为没有历史数据作参考,一般建议通过业务部门进行评估。

QPS和TPS之间的区别,也是很多新手刚接触时容易搞混的,那他们之间到底有什么区别和联系。

一般来说,QPS基本类似于TPS,但不同的是,对于一个页面的一次访问,会形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就会计入“QPS”之中。

如果是对一个接口(单场景)压测,且这个接口内部不会再去请求其它接口,那么TPS=QPS。

例如:访问一个 Index 页面会请求服务器 3 次,包括一次 html,一次 css,一次 js,那么访问这一个页面就会产生一个“TPS”,产生三个“QPS”。

对于衡量单个接口服务的处理能力,一般采用QPS比较多,一般如果衡量事务业务场景的处理能力一般则采用TPS。

注:Jmeter聚合报告中,Throughput是用来衡量吞吐量,通常是由TPS来表示。

4. 小结

一个系统处理性能能力通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等其它消耗导致系统性能下降。

影响系统响应时间由CPU运算、IO、外部系统响应等因素组成。一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等紧密关联,单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。

最后,几点小结和建议:

  • 系统的性能一般由TPS决定,跟并发用户数没有太大直接关系。
  • 系统的最大TPS是一定的(在一个范围内),但并发用户数不一定,可以调整。
  • 建议性能测试的时候,不要设置过长的思考时间,以最坏的情况下对服务器施压。
  • 一般情况下,大型系统(业务量大、机器多)做压力测试,10000~50000个用户并发,中小型系统做压力测试,5000个用户并发比较常见。
  • 通过系统的监控工具,发现系统的性能瓶颈,通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等,而缓存系统容易发生瓶颈的地方是内存,储存型系统则是I/O。

并发用户这些用户的最大特征是和服务器会产生交互,这种交互既可以是单向的传输数据,也可以是双向的传送数据。

更多测试开发技术干货,请关注公众号:【测试开发技术】

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
9天前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
25 2
|
4天前
|
缓存 Java 测试技术
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
使用JMeter对项目各个接口进行压力测试,并对前端进行动静分离优化,优化三级分类查询接口的性能
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
|
5天前
|
测试技术
测试用例设计方法之基本路径测试法
基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法,设计出的测试用例要保证在测试中程序的语句覆盖100%,条件覆盖100%
17 7
测试用例设计方法之基本路径测试法
|
5天前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
29 7
Jmeter实现WebSocket协议的接口测试方法
|
4天前
|
敏捷开发 数据可视化 Devops
敏捷测试价值观、方法和实践读书笔记(4)
本章节探讨了敏捷测试执行的关键概念与实践。首先介绍了用户故事及其重要性,强调其在敏捷开发中的角色,并阐述了用户故事的 INVEST 原则。接着分析了用户故事生命周期中的测试关注点,包括定义、处理、完成及验收阶段的测试活动。此外,还对比了不同测试术语的差异,并提供了敏捷测试计划的策略与过程。通过看板等工具实现任务管理与跟踪,确保测试活动高效进行。最后,介绍了敏捷测试中的度量指标,帮助团队评估测试效果。
16 5
敏捷测试价值观、方法和实践读书笔记(4)
|
4天前
|
监控 架构师 Devops
敏捷测试价值观、方法和实践读书笔记(3)
本章节介绍敏捷测试转型框架,涵盖模型概览、实施难度与顺序、文化转变、角色技能需求及测试流程。敏捷测试转型模型包括文化、组织、流程与实践等关键要素,并针对各层面提出具体实施建议与障碍解决方案。此外,详细阐述了不同敏捷测试角色的技能需求与职责,以及从Sprint内至跨Sprint的测试流程与交付物。
15 5
敏捷测试价值观、方法和实践读书笔记(3)
|
4天前
|
开发框架 数据可视化 项目管理
敏捷测试价值观、方法和实践读书笔记(1)
敏捷软件开发宣言在身体力行的同时也帮助我们一直在实践中探寻更好的软件开发方法。由此,我们建立了如下价值观:个体和互动 高于 流程和工具工作的软件,高于 详尽的文档客户合作, 高于 合同谈判响应变化,高于 遵循计划。也就是说,尽管右项有其价值,但我们更重视左项的价值。
21 4
敏捷测试价值观、方法和实践读书笔记(1)
|
4天前
|
JavaScript 前端开发 Java
敏捷测试价值观、方法和实践读书笔记(5)
本章节介绍了敏捷功能测试的原则与实践,包括单元测试的概念及其编写步骤,测试驱动开发(TDD)的流程,以及如何通过模拟对象进行测试。详细讲解了单元测试的编写方法,如初始化对象、执行操作及验证结果,并探讨了 TDD 的五个步骤。通过具体案例展示了如何逐步完善储蓄账户的功能测试,包括存款、取款及异常处理。此外,还讨论了代码覆盖率的重要性及其局限性,强调了测试充分性比单纯追求代码覆盖率更为关键。
11 3
敏捷测试价值观、方法和实践读书笔记(5)
|
4天前
|
机器人 测试技术
敏捷测试价值观、方法和实践读书笔记(6)
验收测试驱动开发(ATDD)强调在开发前定义验收标准,并通过自动化测试确保用户价值得到满足。验收测试关注用户需求是否实现,而非代码细节。ATDD涉及用户、产品负责人、开发人员及测试人员,通过讨论、开发和交付三个阶段,确保产品符合预期。此方法有助于团队更好地理解和实现用户需求。
17 5
|
4天前
|
敏捷开发 测试技术
敏捷测试价值观、方法和实践读书笔记(2)
本章节介绍敏捷测试在快速变化的软件开发环境中的重要性。传统测试方法在敏捷环境中面临时间紧迫、文档不足、频繁变更及资源短缺等挑战。敏捷测试遵循敏捷开发原则,强调测试与开发的紧密融合、团队协作及业务价值交付。其特点包括更强的协作、更短的周期、更灵活的计划及高效的自动化。相较于传统测试,敏捷测试具有加快产品上市时间、提升整体质量及简化流程降低成本的优势。
11 3