性能测试实战 30 讲
高楼
前 HP 高级性能专家,7DGroup 创始人
45941 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 37 讲
性能测试实战 30 讲
15
15
1.0x
00:00/00:00
登录|注册

14丨性能测试场景:如何理解业务模型?

业务模型计算过程
生产数据统计
在执行场景过程中控制TPS比例的方法
业务比例对性能场景的重要性
在执行场景过程中控制TPS比例的方法
业务比例对性能场景的重要性
业务模型的来源和计算过程
TPS的控制
16点的业务模型
9点钟的业务模型
通用业务场景模型
以小时为单位做出百分比图
生产TPS量级的统计
以分钟为单位看业务量分布
以小时为单位统计业务量比例
业务量比例的计算
业务量最高的一天
业务量级按天统计
粒度到秒级
从生产环境取出数据
技术实现和高层领导支持的难点
直接在生产环境中通过业务统计动态统计出业务场景的方式
流量回放过程中遇到的问题
观点批驳:只有通过生产流量回放的方式才是真实地模拟了线上的流量
在数据库中回放SQL
接口的回放
在执行场景过程中控制TPS比例的方法
业务比例对性能场景的重要性
业务模型的来源和计算过程
业务模型的重要性
通过生产流量回放实现压力部分
线上业务模型与真实项目中的差异
性能测试场景中的重要性
问题
总结
业务模型计算过程
生产数据统计
回放的逻辑
业务模型
性能测试场景:如何理解业务模型?

该思维导图由 AI 生成,仅供参考

性能场景中的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中,业务模型跟线上的业务模型不一样的情况实在是太多了。原因可能多种多样,这些原因大大降低了性能测试的价值。
有人说,就是因为这样才应该直接用生产流量的方式来做嘛,这样就不用管业务模型了,直接就有生产的业务模型了。没错,只要你能通过生产流量扩大回放的方式实现压力部分,确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。

回放的逻辑

回放的逻辑是这样的。
如果你喜欢的话,还可以在每一个业务产品和基础架构的层面做接口的回放,甚至我们可以直接在数据库中回放 SQL。而这些手段,都是为了模拟生产的业务模型。
这是非常容易理解的逻辑吧。
这里要批驳一个观点,就是有些人觉得只有通过生产流量回放的方式,才是真实地 模拟了线上的流量。事实上,这个观点是偏颇的。前几天有一个性能测试工程师问我一个流量回放过程中遇到的问题,谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确,但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景,最后折腾了一个月也是无功而返。
我知道,现在有很多人在各种场合说,可以直接在生产环境中,通过业务统计动态统计出业务场景,并实时实现到性能平台中去。这当然是一个很好的路子,但这个路子需要完整的技术实现,并且在不同的企业中,这种方式难就难在创建业务模型的统计算法,此外还要有高层领导的支持,才能真正实现完整的逻辑。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

性能测试场景中的业务模型对于性能测试工作非常重要。文章介绍了从生产数据统计到业务模型计算的过程,强调了业务比例对性能场景的重要性,并提出了如何在执行场景过程中控制TPS比例的问题。作者指出,无论采用何种手段来模拟生产环境的流量,最终目标都是实现和线上接近的业务模型。文章强调了业务模型的重要性,以及在性能测试过程中控制TPS比例的必要性。通过对生产数据统计和业务模型计算的详细描述,读者可以了解到如何从实际数据中获取业务场景,并将其转化为性能测试的业务模型。文章内容技术性强,对性能测试工程师具有一定的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《性能测试实战 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(58)

  • 最新
  • 精选
  • SeaYang
    1、为什么业务比例对性能场景如此重要? 业务比例一般都是从生产数据统计来的,设置这样的比例能够更真实地模拟生产流量模型 2、如何在执行场景过程中控制 TPS 比例呢? 以jmeter为例,我们使用的是Throughput Shaping Timer和Weighted Switch Controller这两个插件。Weighted Switch Controller是比例控制器,控制的是压力的比例,其实也是控制了TPS的比例了,这个时候随着线程数增加,TPS一般会往上增加直到达到最大TPS。另外,我们还会使用控制接口最大TPS的方式去压,这个时候就会用到Throughput Shaping Timer,这个是控制接口最大TPS的元件,如果多个接口都在一个线程组里面的话,需要和比例控制器一起使用,如果在不同的线程组,则不需要

    作者回复: 一看就是有实践经验的。优秀!

    2020-11-06
    2
    21
  • number717
    高老师,这里的业务肯定是包含了多个接口,你这里的业务是怎么统计的啊,在网关上只能看到每个接口的调用量,有的接口可能在多个业务中都有调用,这怎么统计啊?可不可以大概说说您的业务是怎么统计出来的啊?

    作者回复: 不同的角度。举个例子,在电商系统中要下一个订单,对用户就是点个按钮,对后面的每个系统都会产生调用。我们从这个按钮开始往后捊的话,就可以有一个业务路径图了。 直接从接口上是比较难统计出业务逻辑的。

    2020-09-16
    3
    10
  • Taylor
    Elk分析业务比例具体细节能介绍下吗

    作者回复: 暂时没有计划说这一块的内容。等后期全部更新完毕之后,如果有更多人询问这个问题。再考虑是否加餐。

    2020-01-15
    8
  • 顺利
    老师我的问题如下,望得到解答: 1.用业务比例来进行容量测试时,用Constant Throughput Timer控制了tps,是不是就压不到最大值了,受限于所设置的tps值,觉得这里设置的tps和想要得到的最大TPS值冲突了 2.用业务比例来进行容量测试时,是不是需要同时使用吞吐量控制器(来控制业务的百分比)和常数吞吐量定时器(控制总TPS),如果不是,那应该怎么实现呢。

    作者回复: 1,控制了时间的话,如果最大tps之前就达到了控股的时间,肯定就测试不出最大tps了呀。 2,是。

    2020-02-20
    4
    6
  • 律飛
    1.为什么业务比例对性能场景如此重要? 不同的业务对系统资源的消耗完全不一样,如果业务比例跟实际的业务比例不一样,就会导致运行过程中资源消耗出现很大的偏差,那么得到的结果不够真实正确,也大大降低了性能测试的价值。 另外,如果生产流量来源是可以覆盖想要测试的业务场景的,可以通过生产流量扩大回放的方式实现压力部分,就不用考虑业务场景了。 2.如何在执行场景过程中控制 TPS 比例呢? 通常,在 LoadRunner 里,会用pacing来控制 TPS,而用 JMeter 的,则会用Constant Throughput Timer来控制 TPS。注意,JMeter中,Throughput Controller并不控制TPS。 另外请教老师,根据业务模型推算出各业务的TPS,从而根据公式,结合响应时间推算出压力机线程数。这个思路对吗?如果对,如何进一步确定压力机线程数配置,具体来说,问题1,响应时间怎么获取?是业务提出的,还是基准测试中获得的最大TPS对应的响应时间?问题2,推算出来的压力机线程数就是测试中的最大值吗?是否需要适当加大一些呢?如果需要,增加多少合适?如果不是测试中的最大值,怎么取值?问题3,在一次场景测试中,业务模型是一直要保持吗?比如说,起始线程数的配置也是要按业务比例计算吗?中间任一时刻都得按业务比例设计吗?

    作者回复: 思路是对的。 问题1:按基准测试中获取的最优响应时间来计算。 问题2:递增的比例要看具体场景了,和响应时间,tps量级,业务特点都会有关。增加比例就参考我写的经验值就行了。 问题3:业务模型是要一直保持的。所以不能只看线程数,而应该强调tps比例的一致性。

    2020-01-17
    2
    6
  • qtracer
    还是有点不明白,虽然罗列了三种业务模型,但什么情况下使用哪种并没有很好的说明。这块希望老师解答下。

    作者回复: 不是使用哪种。而是哪种都要覆盖。

    2022-05-10
    4
  • 败给了自己
    老师,你好,有两个疑问。1、上面按小时的统计中,业务集中在早上9点到凌晨,在凌晨到早上9点基本很少业务。而通用模型中,按照24小时来算tps指标,合适吗? 2、每天的业务量2000万是估算的吗? 实际上凌晨到早上这段时间系统业务量基本没有,对这段时间对性能测试来说基本就是无效时间吧。所以我认为一天的业务量没有两千万。 大约可以按照15小时有效时间,估算每小时70万(亦或计算平均值)。tps1=700000/3600=194。 我刚觉tps1=231,是偏高了的 。

    作者回复: 1, 通用模型按有业务的平均来算即可,这个系统说是24小时的。 2,是偏高的。性能模型就是要偏高一点。

    2020-06-20
    4
  • 赫拉
    问题1:业务比例不一样,对系统的资源消耗可能不一样,性能的目的就是模拟生产的情况提前发现系统的问题从而解决掉它。 高老师,请教下:业务比例是针对系统的所有业务给出来的,但实际压测,并不是要压测所有的业务,例如,系统有4个业务分别为A、B、C、D,他们的业务比例分别为40%、30%、20%、10%,假如本次压测是业务B、C,A和D不做压测,那容量测试的业务比例是设置合适呢

    作者回复: 这个就是针对性的测试了,在我的逻辑中,不能做为容量场景的模型,可以做为基准测试的模型。因为业务覆盖不完整。

    2020-04-04
    4
  • johnny
    引用内容 开始================================================================= 2、3可以这么说: 比如,有这些接口:登录、查询商品、添加购物车、创建订单、支付 我们通过日志分析,都是这些接口的比例吧?假设比例分别是:20:40:20:10:10 实际业务场景可能是这样的: 1、登录--查询商品--添加购物车--创建订单--支付 2、登录--查询商品--添加购物车 3、查询商品 那以上3个流程,如何算分别是多少比例呢? 作者回复: 3个流程的比例是: 1. 25% 2. 25% 3. 50% 引用内容 结束================================================================== 老师,关于引用内容中有以下6个问题,麻烦老师再次解答下。 1.登录、查询商品、添加购物车、创建订单、支付。这5个业务我可不可以理解为业务操作级别的事务T?(第二个专栏中定义了事务T有请求级别、业务操作级别、用户级别) 2.登录、查询商品、添加购物车、创建订单、支付的比例20:40:20:10:10。这个比例是不是就是业务模型中的业务比例? 3.两个专栏都提到了业务模型。业务模型中的业务指的是哪个级别的事务? 4.3个流程的比例25%、25%、50%。这个比例我可不可以理解为用户级别事务T的比例? 5.就拿登录来说,它下面应该包含多个get或post请求,有静态资源请求,有接口请求,其它4个业务查询商品、添加购物车、创建订单、支付下面也包含多个get、post请求,而且某些get或post请求在5个业务中都会被调用。这么多的请求在日志中混在一起,怎么才能得出业务比例20:40:20:10:10?我看老师提到用ELK,不过可以简单的说下背后的原理吗。(备注:我接触过的应用是单体应用nginx-tomcat-mysql,不是微服务。不过我想专栏中业务模型比例计算的逻辑是通用的,应该和架构没关系。) 6.专栏中的接口该怎么理解,接口对应哪个级别的事务?

    作者回复: 1. 这是典型的业务操作级别的事务。 2. 是。 3. 业务操作级别的。 4. 流程是由业务级别的事务组成的,所以流程显然是用户级别的事务。 5. 统计接口的比例,再对应相应的业务操作就可以了。 6. 接口就是业务级别的事务。

    2021-08-06
    3
    3
  • 勼乄児亓
    老师,有几个疑问,希望能解答: 1,业务比例我是用 控制器中的“吞吐量控制器”来控制的,这样做跟Constant Throughput Timer有什么区别吗? 2,业务模型统计的数据,是统计接口的请求次数,还是什么? 3,当压测环境与生产环境不是1:1时,运维大概估算一个环境比例,压测过程中,业务指标,铺底数据量也要做同比例缩放?还是铺底数据是根据存储服务网来做同比例缩放的?

    作者回复: 1,这两个控制器是完全不同的逻辑。Constant throughout Timer 只是一个定时器,它固定了指定线程在单位时间内发出去的请求数。 这个比例控制,我建议用throughout controller,它才在线程连续递增的过程中控制请求的比例。 2,看场景目标是什么,如果只是为了测试接口,那就只统计接口就可以了。如果要测试的包括静态资源,那就得都统计出来。 3,这个要先做基准测试,才能判断多少铺底数据是合理的。

    2020-12-24
    3
收起评论
显示
设置
留言
58
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部