2022年探讨性能测试的负载目标归类 .pdf

上传人:Q****o 文档编号:28525950 上传时间:2022-07-28 格式:PDF 页数:4 大小:90.78KB
返回 下载 相关 举报
2022年探讨性能测试的负载目标归类 .pdf_第1页
第1页 / 共4页
2022年探讨性能测试的负载目标归类 .pdf_第2页
第2页 / 共4页
点击查看更多>>
资源描述

《2022年探讨性能测试的负载目标归类 .pdf》由会员分享,可在线阅读,更多相关《2022年探讨性能测试的负载目标归类 .pdf(4页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。

1、 探讨性能测试的负载目标性能测试主要评价系统或组件的性能是否和具体的性能需求一致,例如:对访问速度的性能需求或对内存使用情况的需求。特定性能测试的关注点在于组件或系统在规定的时间内和特定的条件下响应用户或系统输入的能力。一、前提近期我跟踪了 2个外协人员参与的性能测试项目,沟通中发现大家在制定测试策略时对如何确定负载目标、计算并发用户数量等方面有很多不同方法,本文希望能对各种方法进行探讨, 并根据已有经验对策略制定方面给出一些自己的建议。本文被测应用以银行系统为主,压力发起工具以LoadRunner为例。二、术语单位时间:本文中以1秒为单位时间。在线用户数量: 访问被测应用的用户数量,但单位时

2、间内用户不会同时对被测服务器发送请求,产生压力。并发用户数量: 部分书中分狭义和广义两种,狭义指单位时间内同时执行一种操作的用户数量, 广义指单位时间内同时执行多种不同操作的用户数量,广义的并发用户操作更接近实际业务环境。但本文中的并发用户数量仅指狭义而言,因为广义是多种狭义的组合。TPS :Transaction per Second,每秒事务数量,单位是事务/ 秒。TRT :Transaction Response Time,事务响应时间, 指TPS 稳定时的平均事务响应时间,单位是秒。三、负载目标1. 负载视角制定测试策略是性能测试的重点,包括测试范围、场景提取、负载目标、发起方式、通过

3、标准等。 而负载目标关系整个测试的场景设计、并发配比、 结果评判,因此确定负载目标也决定了测试的总体方向。通过了解业务需求,负载目标都会转化为一系列具体的数值,一般可从两方面来划分:前端:业务人员更关注前端并发用户数量或在线用户数量,以人数衡量;后端:技术人员更关注后端应用服务器和数据库服务器的负载能力,以TPS 衡量;名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页,共 4 页 - - - - - - - - - 前端并发用户数量的计算在业界中有很多公式和原则,如2/8 原则

4、、10% 在线用户数量估算、 (在线用户数量*session 时间) / 监控时间等, 但各公式和原则计算出的并发用户数量并不精确,如有 10万在线用户的系统不能说仅测试10万*10%=1万并发用户即可。后端 TPS 反应被测应用的实际负载能力,对已有具体业务量的应用可以计算精确,如银行系统中某省行对公交易量日均10万笔,则可精确计算出TPS 均值 =10万/ (6*3600 )=4.63笔/ 秒(对公业务按6小时计算),若被测应用达不到TPS 要求则完成不了当日业务。同一个被测应用以不同视角估算负载目标,得到的数值可能会有很大差异,因此如何正确选择负载目标,将会直接影响之后的测试方法和场景设

5、计。2. 负载指标抛开视角的选择,单从最终测试指标来说,对于一个软硬件环境固定的应用程序,只有一个负载指标是固定的,那就是最大事务处理能力 通常以 TPS 衡量。随着负载的增加,被测应用将会逐渐达到最大事务处理能力,若应用足够健壮,则负载继续增加,应用的事务处理能力也不会骤然下降。因此性能测试的目标就是确定被测应用的最大事务处理能力。以事务处理能力反推,将逐渐捋清TPS 、TRT 、并发用户数量、在线用户数量等负载目标的关系和估算。1)TPS Transaction的粒度会直接影响TPS 的计算,因此 Transaction定义时要保证粒度适当:C/S架构联机类应用中一笔交易往往会流经多层前置

6、应用,需要确定压力发起工具所在位置,建议跨过前端直压被测应用,此时一个Transaction代表一支后台交易。B/S架构经管类应用中一个页面操作可能会和后台有多次交互,建议以页面上的操作为Transaction划分基准,但要保证Transaction内的交互操作在前端是不可再拆分的。LoadRunner发起压力时 Action 内的语句是反复迭代的,而LR计算 TPS 仅看 1秒内执行了几次Transaction,如果 Action内有多个 Transaction则各事务的 TPS 都一样, 反应不出各事务的真实处理能力,因此建议Action 内只定义一个或尽量精简的 Transaction。

7、由此 TPS 才可以准确表示被测应用的事务处理能力。通过获取生产日志、参考相似系统等方式能够得到具体交易(事务) 数量的被测应用程序,以 TPS 为负载目标是直接也最准确的。但要注意,若以 TPS 为目标,则前端配置的并发数量就不再代表并发人数,而是并发提交事务的数量。TPS 和 TRT 的计算关系将在下面详述。2)TRT TRT 指TPS 稳定时(不一定是最大时)的平均事务响应时间,不关注个别事务,它和TPS关系紧密,随 TPS 的变化而变化。当负载增加时TRT 会逐渐增大,直至事务阻塞,交易超时。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - -

8、- - - - - 名师精心整理 - - - - - - - 第 2 页,共 4 页 - - - - - - - - - TPS TRT = 并发提交事务的数量。如果以TPS=20 为目标,且此时TRT=2 秒,则并发提交事务的数量 =202=40笔。如果 1个用户单位时间内提交1笔事务,则可等于有40个并发用户数量。设定好目标 TPS 后要同时兼顾 TRT 的表现,若 TRT 明显超出业务要求,即使达到负载目标也是无效的。 TRT 无固定的好坏标准,一般来说对 OLTP 的联机应用, 从前端提交到返回不应高于 3秒,后台应用程序和数据库的处理应在1秒左右。 对OLAP 的在线分析系统或一般网

9、站可遵循 3/5/8 原则,或更长。3)并发用户数量通常理解并发用户数量就是LoadRunner里设置的 VUser数量,通过梯度增加 VUser,对比TPS 变化即可找到被测应用的最大并发用户。但我却认为并发用户数量不等于LoadRunner中设置的 VUser数量。受交易响应时间、thinktime、pacing 和集合点等因素影响, VUser数量不能直接体现被测应用负载能力。假设同样 10个VUser并发一次, 如果 A程序的响应时间是1秒,则 A程序的 TPS=10/1=10。 而B程序的响应时间是5秒,则 B 程序的 TPS=10/5=2。同样在混合场景中用VUser比例体现不同应

10、用的负载比例也是错误的,混合场景下由于各交易相互影响,单交易负载时响应快的很可能现在出现阻塞,前端VUser的比例根本无法准确控制后端应用的压力。因此我更愿意将“并发用户数量”和“并发提交事务数量”挂钩,体现被测应用实际负载:单位时间内n个用户并发向被测应用提交n个事务请求(n是相同的)。VUser的数量和发起设置只是实现并发用户数量的一种手段。4)在线用户数量在线用户数量与并发用户数量、TPS 、 TRT 间没有固定的换算公式,我不提倡10% 这样的粗糙比例,对联机类应用在线用户就是每天签到的柜员数量,对经管类应用就是月末、季末时所有登录系统的用户数量。在线用户数量可以从需求人员或生产管理员

11、处获得大概数值,但不能通过性能测试倒推出在线数量。四、负载目标选择1. 有明确交易量的应用通过上面对各种典型负载指标的分析可以看出,以TPS 衡量的事务处理能力是最准确的负载目标。 通过生产日志或相似系统的交易量可以算出TPS 均值、 峰值。根据2/8 原则和业务扩展可估算更高的峰值。银行的联机类应用属于典型的有明确交易量的应用系统。LoadRunner中可以通过设置Run-Time Settings的Pacing 为 At fixed intervals, every 1 sec ,来控制每次迭代执行时间为1秒。如果迭代脚本里只定义一个Transaction,且 TRT小于 1秒,则 VUs

12、er数量 =并发用户数量 =TPS, 可以通过调节VUser数量方便控制负载目标。注意, 如果迭代中包含多个Transaction,或TRT 随着 TPS 目标的增加而变大,则需以 TPS 目标名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页,共 4 页 - - - - - - - - - 为基础,实时调整VUser数量和这里 every N sec里的间隔时间。2. 无明确交易量的应用无明确交易量的被测应用建议以确定最大事务处理能力为目标。设置Pacing 为As soon

13、as the previous iteration ends,删除 thinktime,部署发压工具和被测应用在同一网段,无网络瓶颈,让VUser能对被测应用产生最大负载。弱化VUser数量听上去的意义,递增直到达到被测应用的最大事务处理能力或其他性能指标阀值(如成功率或TRT ) 。新业务和经管类Web 应用属于无明确交易量的应用系统。3. VUser 的意义尽管建议在确定负载目标时弱化VUser的意义,但测试中还要注意一种情况,如果被测应用有具体的操作用户数量,如只有签到或登录的用户才能提交交易,则VUser的数量不能高于实际注册用户数量。就按照最大用户数量加压,以需求要求的 TRT 为目标调优被测应用,尽量提高 TPS 。希望本文能给你带来帮助。(ps:本文章来源于北大青鸟广安门校区官网)名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页,共 4 页 - - - - - - - - -

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 技术资料 > 技术总结

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知得利文库网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号-8 |  经营许可证:黑B2-20190332号 |   黑公网安备:91230400333293403D

© 2020-2023 www.deliwenku.com 得利文库. All Rights Reserved 黑龙江转换宝科技有限公司 

黑龙江省互联网违法和不良信息举报
举报电话:0468-3380021 邮箱:hgswwxb@163.com