性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
4054 人已学习
课程目录
已更新 24 讲 / 共 30 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
第二模块:性能测试工具及性能场景篇 (9讲)
07丨性能测试工具:如何录制脚本?
08丨案例: 手把手教你编写最简单的性能脚本
09丨关联和断言:一动一静,核心都是在取数据
10丨案例:在JMeter中如何设置参数化数据?
11丨性能脚本:用案例和图示帮你理解HTTP协议
12丨性能场景:做参数化之前,我们需要考虑什么?
13丨性能测试场景:如何进行场景设计?
14丨性能测试场景:如何理解业务模型?
15丨性能测试场景:如何进行监控设计?
春节策划 (2讲)
春节策划丨性能评估和性能分析试题,等你挑战!
春节策划丨快来挑战一下自己的分析逻辑吧!
第三模块:性能监控分析工具篇 (6讲)
16丨案例:性能监控工具之Grafana+Prometheus+Exporters
17丨CentOS:操作系统级监控及常用计数器解析(上)
18丨CentOS:操作系统级监控及常用计数器解析(下)
19丨Java & C ++:代码级监控及常用计数器解析(上)
20丨Java & C ++:代码级监控及常用计数器解析(下)
21丨Tomcat:中间件监控及常用计数器解析
性能测试实战30讲
登录|注册

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

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

回放的逻辑

回放的逻辑是这样的。
如果你喜欢的话,还可以在每一个业务产品和基础架构的层面做接口的回放,甚至我们可以直接在数据库中回放 SQL。而这些手段,都是为了模拟生产的业务模型。
这是非常容易理解的逻辑吧。
这里要批驳一个观点,就是有些人觉得只有通过生产流量回放的方式,才是真实地 模拟了线上的流量。事实上,这个观点是偏颇的。前几天有一个性能测试工程师问我一个流量回放过程中遇到的问题,谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确,但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景,最后折腾了一个月也是无功而返。
我知道,现在有很多人在各种场合说,可以直接在生产环境中,通过业务统计动态统计出业务场景,并实时实现到性能平台中去。这当然是一个很好的路子,但这个路子需要完整的技术实现,并且在不同的企业中,这种方式难就难在创建业务模型的统计算法,此外还要有高层领导的支持,才能真正实现完整的逻辑。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • kubxy
    老师,您好。我是一名性能测试小白,想请教您一个问题。在做性能测试时,如何理解和定义业务?是实现这个业务逻辑的核心接口,还是完成这个业务操作所涉及到的所有接口?比如,我们目前打算上线一款APP,我想做一下接口的性能测试,评估服务器目前的承载能力,为后期服务器规划扩容提供数据支撑。由于目前没有实际的生产流量,因此我根据APP的特点,站在用户的角度分功能操作APP并用JMeter录制脚本,于是我设计了两个测试方案:
    1.把每个功能看做一个业务,直接用录制的脚本做基准场景和容量场景的性能测试。
    2.把每个功能看做一个业务,从录制的脚本中挑出完成这个功能的核心接口做基准场景和容量场景的性能测试。
    对于我设计的方案,老师能说说您的看法吗?另外,能针对我的这个需求场景,给我一些实施的建议吗?

    作者回复: 你这1和2除了静态资源之外有什么区别?
    如果静态资源线上是放在cdn上,那显然是选择2。
    这个实施建议我不知道你说的是什么,这整个专栏中的都需要在实施中考虑的。像数据,业务比例,场景设计,监控设计等等。

    2020-01-16
    2
  • 仲先生
    高老师,有哪些好用的工具可以辅助分析业务比例么?文中的比例图是怎么画出来的呀?

    作者回复: elk就可以分析呀。比例图用excel就能画。

    2020-01-15
    1
    2
  • 杜艳
    这些图怎么来的 都不知道了

    作者回复: 生产环境中统计来的。excel都行。你有工具可用那就更好了。

    2020-02-07
  • Hanson
    高老师,请问业务数据是怎么统计出来的?

    作者回复: 生产日志统计来的。

    2020-01-21
  • 吴小喵
    Elk分析业务比例具体细节想了解一下

    作者回复: 这个直接统计就好了吧。ELK中有图可以生成,有时间段,有业务量的。

    2020-01-19
  • 律飛
    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
  • Geek_a98085
    老师讲的以tps来承载业务比例,和jmeter中按if控制器来配置不同业务的请求比例,很容易引起混淆。希望老师能澄清下这两个的区别。

    作者回复: if控制器不能控制业务的请求比例呀。 我没有写if控制器哦。

    2020-01-16
  • Geek_a98085
    刚好拿到了一个项目高峰期间的ng日志,正好可以按老师说的实践分析下啦。然后和项目上线前的预估比例和指标进行对比看看偏差。

    作者回复: 做下看看结果。会感觉很有意思的。

    2020-01-16
  • 村夫
    问题一:首先只有混合容量性能测试场景下得出的tps才是最接近服务器能承载的最大或者说最佳容量,而混合容量场景却需要由事先确认好的业务比例来保证这个场景是有效的,最接近线上业务的。
    问题二:我有个疑问,当我们使用Constant Throughput Timer时,肯定是需要事先设置好并发数的,我曾经试过在相同的请求数下,不同的线程数在刚开始跑的时候tps波动不一致,也就是说线程数越大,tps也越大,只不过随着时间推移慢慢接近设置的tps。而设置小的线程数整体的tps确实很平坦的。
    还有就是老师这一次也没见您说递增式的场景?按我理解,无论是单交易还是混合容量,在压测时不应该都用递增式来逐渐达到最大tps吗?
    请老师点评以及回答

    作者回复: 递增是所有场景的默认条件。我觉得前面已经强调的够重了。😃😃

    2020-01-16
  • 、Eif
    每上线一个新系统就要求压压看,然后这时候是没有什么业务峰值的,就根据当前配置代码做个压测得出最大TPS,那么这里说到没根据生产业务模型是没意义的?还有必要做吗

    作者回复: 你这个也就是扫扫上了压力就出现的明显bug,其他没什么用。

    2020-01-15
    1
  • 月亮和六便士
    高老师,看完文章有两个疑问:1 . 在jmeter中,业务比例是依靠什么承载的,是线程数吗?A业务占百分之八十,我就设置A为百分之八十的线程数吗? 2. 那种按照一小时取平均tps 是不是太粗糙? 比如 虽然一小时 是2000万的业务量,但是其中的1000万的业务量是在最高峰的10分钟产生的,高峰的tps其实是16000,

    作者回复: 根据tps承载比例。

    2020-01-15
  • Taylor
    Elk分析业务比例具体细节能介绍下吗

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

    2020-01-15
  • Imaginary
    答:
    1、通过对生产数据统计能够完整体现系统业务的峰值数据,然后转换成具体场景中的业务模型,模拟真实的生产环境中的业务比例。不同的业务对系统资源的消耗完全不一样,如果业务模型跟线上的业务模型不一样,就会导致运行过程中业务比例出现很大的偏差,那么得到的结果不够真实正确,也大大降低了性能测试的价值。
    2、执行场景中控制TPS比例的方法: LoadRunner 里,会用pacing来控制 TPS,而用 JMeter 的,则会用Constant Throughput Timer来控制 TPS。

    作者回复: 看来是理解了。

    2020-01-15
  • NightClown
    第一个问题我认为业务比例越趋近生产环境得到的性能数据越真实,生产流量的回放我理解的核心目的也是为了真实的覆盖所需要测试的性能场景,如果业务比例跟真实环境差距很大,那么得到的数据是没有意义的
    第二个问题控制TPS比例需要根据线上的统计得到每个服务TPS的峰值及范围,不同的天数和时段TPS是不同的,需要根据线上的TPS的比例去测试系统的资源占用和性能指标,这样才能够真实的反应系统的性能情况,不论做系统当前性能测试还是未来系统的容量规划都是有意义的

    作者回复: 理解的很对。

    2020-01-15
    1
收起评论
14
返回
顶部