高楼的性能工程实战课
高楼
盾山科技 CEO,7DGroup 创始人
19172 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 35 讲
特别放送 (1讲)
结课测试 (1讲)
结束语 (1讲)
高楼的性能工程实战课
15
15
1.0x
00:00/00:00
登录|注册

06 | 如何抽取出符合真实业务场景的业务模型?

你好,我是高楼。
我们知道,业务模型一直是性能项目中很重要的环节。在容量场景中,每个业务比例都要符合真实业务场景的比例。如果不符合,那场景的执行结果也就没有意义了。
但是,我们经常可以看到,很多性能从业人员因为对业务模型的抽取过程不够了解,或者是拿不到具体的数据,导致业务模型和生产业务场景不匹配,进而整个性能项目都变得毫无意义。
也有大量的项目,并没有拿历史业务数据做统计,直接非常笼统地拍脑袋,给出相应的业务模型,这样显然也是不合理的。可是,这种情况在金融、互联网等行业中十分常见。
当然,也有人为了让业务模型和真实业务场景尽可能匹配,会直接拿生产环境的请求进行回放。可是,即便我们拿生产环境的请求录制回放了,也不能保证业务模型和未来的业务场景一致,因为未来的业务场景会随着业务推广而变化。
所以说,我们在做场景时首先要明白,当前的场景是要模拟历史业务场景,还是未来业务场景。
如果是未来的业务场景,那就要靠业务团队给出评估,而非性能团队。不过,在当前的性能市场中,经常有企业要求性能团队给出业务模型,这显然是不理智的。首先,性能团队的业务背景不如业务团队更熟悉;其次,他们对业务市场的把握也不够专业。
其实,在真实的工作场景中,业务模型的确认从来都不应该由一个团队来做,而应该由业务团队、架构团队、开发团队、运维团队和性能团队共同确定,并最终由项目的最上层领导确认。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了如何抽取符合真实业务场景的业务模型,强调了业务模型在性能项目中的重要性。作者提出了两个主要步骤:抽取生产业务日志和梳理业务逻辑。在抽取生产业务日志方面,文章介绍了使用命令和ELFK抽取生产业务日志的方法,并提供了具体的命令示例和ELFK的安装配置步骤。通过这些方法,可以得到对应的业务比例,从而抽取出符合真实业务场景的业务模型。在梳理业务逻辑方面,文章指出根据接口的量级梳理业务逻辑,以更真实地模拟生产业务场景。总结时,强调了抽取时间、抽取范围和业务比例在场景中的实现的关键点,并鼓励读者认真思考两个问题:为什么性能场景中要模拟出真实业务比例?抽取生产数据并最终得到业务模型的步骤是什么?整体而言,本文提供了实用的技术指导,有助于读者快速了解如何抽取符合真实业务场景的业务模型。

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

全部留言(24)

  • 最新
  • 精选
  • Geek_081377
    在这个示例中,大概有 58% 的用户会完整地走完流程。为什么是 58% 呢?因为登录的业务比例是 12%,而后面下单比例是 7%。所以是:7%/12%=58%,这个真没搞懂- -

    作者回复: 仔细想想就明白了。在做脚本时要考虑完整业务流的,而只有一部分走完了,只有把所有线程的58%请求应用到完整业务流才能实现7%的下单覆盖,12%的登录覆盖。

    2021-04-07
    5
    9
  • 米儿
    ELFK系统里有办法截取url统计不?url里带的有id之类的,希望能把这部分模糊掉来统计汇总

    作者回复: 可以在取日志时用logstash截取。

    2021-04-15
    7
  • 言希
    我再最上面看了一些东西不过都是抽取接口级的请求比例,直到看到梳理业务逻辑的讲解,我才放了心;哈哈,可见我们只将请求的数据抽取出来还是不行的,我们还得分析业务场景,只有做完梳理业务逻辑后这个比例才能真的用;

    作者回复: 那是肯定的。性能的最大价值是为了业务稳定服务的,如果没有用户级的业务覆盖,就成了过场和摆设。

    2021-06-11
    5
  • Geek_Gabriel
    抽取线上的请求比例比较容易,把它们转成场景中可用的线程似乎不是太容易。比如总TPS:35,浏览商品目录页17%,浏览商品详情页32%,查询商品20%,加购物车6% ,查看购物车5%,完成下单3%,登录1%。脚本针对以上都有单独线程组在同一个jmx中,但是加购包含详情页,查看购物车包含以上,下单包含所有。像这样的如何设置各线程组的线程数来达到总TPS是35且符合以上业务比例?

    作者回复: 把请求单独列出来。如果有包含关系,就把相应的请求在独立的请求中减掉。

    2021-05-11
    4
  • sierlu
    实际场景很多都是一次登录多次操作,算出来的不一定是百分之多少的在线用户完成了整个流程,这个相对占比算出来感觉意义不大,有点把脚本搞复杂了,不可以直接按照上面表格的比例直接设计脚本么?

    作者回复: 直接设置就得造关联需要的数据。

    2021-06-17
    2
  • 冒冒
    所以在这个示例中,大概有 58% 的用户会完整地走完流程。为什么是 58% 呢?因为登录的业务比例是 12%,而后面下单比例是 7%。所以是:7%÷12%≈58% 业务一 业务二 业务三 业务四 login 786171 12% 5 2 5 home/content 1582439 24% 5 2 5 12 address/list 312741 5% 5 addnew 785595 12% 5 2 5 cart/list 469537 7% 5 2 confirmorder 466036 7% 5 2 generateorder 473535 7% 5 2 order/list 472840 7% 5 2 paysuccess 481271 7% 5 2 detail 794210 12% 5 2 5 20.8% 8.3% 20.8% 50.0% 老师,请问下为啥不是20.8%+8.3%呢?而是58%呢

    作者回复: 中间的请求有重复的。

    2022-01-12
    1
  • jy
    ============评论区引用开始========== 高老师,对于梳理业务逻辑这一步从字面看懂了, 但是不明白得到的结果 【58%用户走完全流程】这个结论,对于性能业务场景分析有什么用 最终定各个接口的TPS也没有用到这个58% 作者回复: 用到了呀。在后面的容量场景中用。 ============评论区引用结束========== 请教: 1、后面容量场景没看到58%的具体应用呢? 2、根据《性能场景之业务模型在性能执行场景中的具体实现逻辑》一文的例子,最后一个业务的比例除以第一个业务的比例,算出来的值和实际脚本设置的比例也不一样。

    作者回复: 1,容量场景中用的脚本就是按这比例设计的,只是没列出来。但跑场景时是用这比例跑的,我是描述了的我记得。 2,最后一个业务除以第一个业务,我没明白啥意思。

    2021-09-06
    1
  • 王晓磊
    业务目标是不是就是说:业务变动很小或者架构改变,总TPS不变;只有业务改变,才对等比例增加总TPS?

    作者回复: TPS肯定是来源于业务的。

    2021-08-30
    1
  • Walker
    高老师,细化时间段里算出的生产TPS是整个系统总的TPS还是单接口的TPS,如果是单接口是不是每个接口都同样的方式计算一遍?

    作者回复: 对的哇。

    2021-05-02
    1
  • 天狼
    今天再看这节课有个疑问,我能得到系统中所有的接口比例,那是不是通过接口比例算出各业模型务间的比例

    作者回复: 如果知道接口的上下关系。是可以算出来的。

    2022-12-07归属地:广东
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部