14丨性能测试场景：如何理解业务模型？
下载APP
关闭
渠道合作
推荐作者
14丨性能测试场景：如何理解业务模型？
2020-01-15 高楼 来自北京
《性能测试实战30讲》
课程介绍
讲述：高楼
时长12:16大小11.21M
性能场景中的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中，业务模型跟线上的业务模型不一样的情况实在是太多了。原因可能多种多样，这些原因大大降低了性能测试的价值。
有人说，就是因为这样才应该直接用生产流量的方式来做嘛，这样就不用管业务模型了，直接就有生产的业务模型了。没错，只要你能通过生产流量扩大回放的方式实现压力部分，确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。
回放的逻辑
回放的逻辑是这样的。
如果你喜欢的话，还可以在每一个业务产品和基础架构的层面做接口的回放，甚至我们可以直接在数据库中回放 SQL。而这些手段，都是为了模拟生产的业务模型。
这是非常容易理解的逻辑吧。
这里要批驳一个观点，就是有些人觉得只有通过生产流量回放的方式，才是真实地 模拟了线上的流量。事实上，这个观点是偏颇的。前几天有一个性能测试工程师问我一个流量回放过程中遇到的问题，谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确，但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景，最后折腾了一个月也是无功而返。
我知道，现在有很多人在各种场合说，可以直接在生产环境中，通过业务统计动态统计出业务场景，并实时实现到性能平台中去。这当然是一个很好的路子，但这个路子需要完整的技术实现，并且在不同的企业中，这种方式难就难在创建业务模型的统计算法，此外还要有高层领导的支持，才能真正实现完整的逻辑。
所以在今天的文章中，我想写的是最朴素的逻辑。那就是从生产数据统计，怎么转化到具体的场景中的业务模型。明白了这个逻辑之后，不管你是用生产流量回放，还是用实时业务量统计，还是线下业务量统计，你会发现原理都是一样的。
这是一个真实的案例，我已经把所有的业务名都替换掉了，同时对业务量级也做了降级调整，但这并不影响描述获取业务场景的完整性。
原系统的量级如下图所示：
这里我将降低 10 倍处理。
生产数据统计
首先我们从生产环境取出数据，粒度到秒级，取出所有业务的交易量数据。
业务量级按天统计的生成图如下：
我为什么要取这一段时间的数据呢？答案很简单，因为这一段时间完整地体现了这个业务系统的峰值数据。
从这样的数据中取出业务量最高的一天，最大的业务量是 2000 万左右。
注意，我这里说的是业务量最高的一天，并不是说我们的业务场景只从这一天产生，还有别的时间，可能业务量不多，但是业务比例会完全不同，这也是要取出来的场景，所以这个统计数据到业务模型的分析过程会比较细致。我们把这一天的逻辑说完后，你就会明白其他的场景获取方式。
接着，我再以小时为单位统计出业务量比例。如下图所示：
从上图显然可以看出哪个小时的业务量最大，那就是 9 点。
但是呢，你不要忘记了，在 16 点的时候，明显蓝色表示的那个业务量是大于 9 点时的业务量的。这个也是要取出来的场景。
如果需要更细的数据，我们可以以分钟为单位看一下这个小时内的业务量分布。
如果你的业务有必要从分钟或秒来看的话，可以按分钟或秒来取场景比例。在我们今天的这个案例中，取到小时就已经足够。因为我要的是业务模型，而不是生产 TPS 量级。
另外，既然说到了这里，我再把生产 TPS 量级的统计说一下。有了上面的分钟统计比例，就可以很容易统计出生产环境中每个业务的最大 TPS 了。这里得到的 TPS 将是最有效的测试是否通过的 SLA 指标。
下面我们再以小时为单位做出百分比图。
为什么要做百分比图呢？因为这个比例才是我们在性能场景中设置的 TPS 比例，是最直接有效的比例。
业务模型计算过程
针对这一天中的数据，我们将做出以下三个业务模型。
通用业务场景模型。就是将这一天的所有业务数加在一起，再将各业务整天的交易量加在一起，计算各业务量的比例。
9 点钟的业务模型。将 9 点钟的业务比例直接拿出来用。
16 点的业务模型。将 16 点钟的业务比例直接拿出来用。
首先我们看一下通用业务模型。
我们将上面的 0% 的业务全部删除，再计算一次百分比，得到测试场景中的业务比例。如下所示：
做为最基础的业务比例，这个可以覆盖大部分的业务时间了。
在通用的业务场景中，如果业务团队有给出明确的 TPS 指标，那就有依赖了。但是，如果没有给的话，也不要气馁。我们可以根据系统的运行时段，计算平均值即可。
因为我们这个系统是 24 小时系统，所以我用 24 小时来计算。得到如下值：
也就是说通用场景中，TPS 不能低于 231。
接着我们看下 9 点的业务模型。计算方法和上面一样，最后得出比例。
我们可以从小时图中看到，9 点的业务量总和有 120 万左右。为了方便，这里我拿 120 万来计算。它的生产 TPS 就是：1,200,000 / 3600 = 333。
显然，这个模型下做场景时就不能低于 333TPS。
最后看一下 16 点的业务场景。
从小时图中，我们可以看到，16 点的业务量总和有 100 万左右。为了方便，这里我拿 100 万来计算。它的生产 TPS 就是：
显然，这个模型下做场景时就不能低于 277TPS。
但是请注意，像 9 点业务模型中的业务 11，占比达到 30.25%；而 16 点业务模型中只有 8.69%。虽然 TPS 差不多，但是业务比例差别大，这两种业务模型下，对系统资源的消耗会完全不一样。
最后我稍微说一下 TPS 的控制。
有了这个计算过程，当我们把这些比例设计到场景中去的时候，一定要注意这些 TPS 的比例在运行过程中，不能发生大的变化。一旦压力发起后，由于各业务的响应时间随着压力的增加发生的变化量不同，就会导致运行过程中业务比例出现很大的偏差。
我们做性能测试工程师的，都有过这样的经历。通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。
总结
在这一篇中，我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算，只要判断出哪一段业务是我们需要的就可以了。
另外我也强调了，不管用什么炫酷的手段来实现生产环境的流量模拟，最终的目标是实现和线上比较接近的业务模型。不是说一定用生产流量回放才是正确的，只有适合自己企业的手段才是最正确的。
问题
那么最后给你留两个问题，为什么业务比例对性能场景如此重要？以及如何在执行场景过程中控制 TPS 比例呢？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享赞 7
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
13丨性能测试场景：如何进行场景设计？
下一篇
15丨性能测试场景：如何进行监控设计？
精选留言(57)
SeaYang2020-11-061、为什么业务比例对性能场景如此重要？ 业务比例一般都是从生产数据统计来的，设置这样的比例能够更真实地模拟生产流量模型 2、如何在执行场景过程中控制 TPS 比例呢？ 以jmeter为例，我们使用的是Throughput Shaping Timer和Weighted Switch Controller这两个插件。Weighted Switch Controller是比例控制器，控制的是压力的比例，其实也是控制了TPS的比例了，这个时候随着线程数增加，TPS一般会往上增加直到达到最大TPS。另外，我们还会使用控制接口最大TPS的方式去压，这个时候就会用到Throughput Shaping Timer，这个是控制接口最大TPS的元件，如果多个接口都在一个线程组里面的话，需要和比例控制器一起使用，如果在不同的线程组，则不需要展开作者回复: 一看就是有实践经验的。优秀！
20
number7172020-09-16高老师，这里的业务肯定是包含了多个接口，你这里的业务是怎么统计的啊，在网关上只能看到每个接口的调用量，有的接口可能在多个业务中都有调用，这怎么统计啊？可不可以大概说说您的业务是怎么统计出来的啊？作者回复: 不同的角度。举个例子，在电商系统中要下一个订单，对用户就是点个按钮，对后面的每个系统都会产生调用。我们从这个按钮开始往后捊的话，就可以有一个业务路径图了。 直接从接口上是比较难统计出业务逻辑的。
共 2 条评论8
Taylor2020-01-15Elk分析业务比例具体细节能介绍下吗作者回复: 暂时没有计划说这一块的内容。等后期全部更新完毕之后，如果有更多人询问这个问题。再考虑是否加餐。
7
顺利2020-02-20老师我的问题如下，望得到解答： 1.用业务比例来进行容量测试时，用Constant Throughput Timer控制了tps，是不是就压不到最大值了，受限于所设置的tps值，觉得这里设置的tps和想要得到的最大TPS值冲突了 2.用业务比例来进行容量测试时，是不是需要同时使用吞吐量控制器（来控制业务的百分比）和常数吞吐量定时器（控制总TPS），如果不是，那应该怎么实现呢。展开作者回复: 1，控制了时间的话，如果最大tps之前就达到了控股的时间，肯定就测试不出最大tps了呀。 2，是。
共 4 条评论6
律飛2020-01-171.为什么业务比例对性能场景如此重要？ 不同的业务对系统资源的消耗完全不一样，如果业务比例跟实际的业务比例不一样，就会导致运行过程中资源消耗出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。 另外，如果生产流量来源是可以覆盖想要测试的业务场景的，可以通过生产流量扩大回放的方式实现压力部分，就不用考虑业务场景了。 2.如何在执行场景过程中控制 TPS 比例呢？ 通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。注意，JMeter中，Throughput Controller并不控制TPS。 另外请教老师，根据业务模型推算出各业务的TPS，从而根据公式，结合响应时间推算出压力机线程数。这个思路对吗？如果对，如何进一步确定压力机线程数配置，具体来说，问题1，响应时间怎么获取？是业务提出的，还是基准测试中获得的最大TPS对应的响应时间？问题2，推算出来的压力机线程数就是测试中的最大值吗？是否需要适当加大一些呢？如果需要，增加多少合适？如果不是测试中的最大值，怎么取值？问题3，在一次场景测试中，业务模型是一直要保持吗？比如说，起始线程数的配置也是要按业务比例计算吗？中间任一时刻都得按业务比例设计吗？展开作者回复: 思路是对的。 问题1：按基准测试中获取的最优响应时间来计算。 问题2：递增的比例要看具体场景了，和响应时间，tps量级，业务特点都会有关。增加比例就参考我写的经验值就行了。 问题3：业务模型是要一直保持的。所以不能只看线程数，而应该强调tps比例的一致性。
共 2 条评论5
败给了自己2020-06-20老师，你好，有两个疑问。1、上面按小时的统计中，业务集中在早上9点到凌晨，在凌晨到早上9点基本很少业务。而通用模型中，按照24小时来算tps指标，合适吗？ 2、每天的业务量2000万是估算的吗？ 实际上凌晨到早上这段时间系统业务量基本没有，对这段时间对性能测试来说基本就是无效时间吧。所以我认为一天的业务量没有两千万。 大约可以按照15小时有效时间，估算每小时70万（亦或计算平均值）。tps1=700000/3600=194。 我刚觉tps1=231，是偏高了的 。展开作者回复: 1, 通用模型按有业务的平均来算即可，这个系统说是24小时的。 2，是偏高的。性能模型就是要偏高一点。
4
汐度清风2022-05-10还是有点不明白，虽然罗列了三种业务模型，但什么情况下使用哪种并没有很好的说明。这块希望老师解答下。作者回复: 不是使用哪种。而是哪种都要覆盖。
3
anti2020-07-22老师，你这边是怎么做到业务统计的？api网关只有接口层的，无业务层的，这块需要怎么做？作者回复: 从接口层也可以统计。但事先你得知道哪些接口组成哪些业务。
共 2 条评论3
赫拉2020-04-04问题1：业务比例不一样，对系统的资源消耗可能不一样，性能的目的就是模拟生产的情况提前发现系统的问题从而解决掉它。 高老师，请教下：业务比例是针对系统的所有业务给出来的，但实际压测，并不是要压测所有的业务，例如，系统有4个业务分别为A、B、C、D，他们的业务比例分别为40%、30%、20%、10%，假如本次压测是业务B、C，A和D不做压测，那容量测试的业务比例是设置合适呢展开作者回复: 这个就是针对性的测试了，在我的逻辑中，不能做为容量场景的模型，可以做为基准测试的模型。因为业务覆盖不完整。
3
仲先生2020-01-15高老师，有哪些好用的工具可以辅助分析业务比例么？文中的比例图是怎么画出来的呀？作者回复: elk就可以分析呀。比例图用excel就能画。
共 2 条评论3
johnny2021-08-06引用内容 开始================================================================= 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. 接口就是业务级别的事务。
共 3 条评论2
😁2020-04-26老师，对于小白来说都有这样的基础问题，业务是怎么定义的，一个接口就是一个业务，还是某个功能的一系列接口统称为一个业务，后者的话是加一个事务控制器实现吗？望老师解惑作者回复: 举例来说，如果一个业务有几个接口，那就单接口先测，再组合起来测试一个业务。
2
kubxy2020-01-16老师，您好。我是一名性能测试小白，想请教您一个问题。在做性能测试时，如何理解和定义业务？是实现这个业务逻辑的核心接口，还是完成这个业务操作所涉及到的所有接口？比如，我们目前打算上线一款APP，我想做一下接口的性能测试，评估服务器目前的承载能力，为后期服务器规划扩容提供数据支撑。由于目前没有实际的生产流量，因此我根据APP的特点，站在用户的角度分功能操作APP并用JMeter录制脚本，于是我设计了两个测试方案： 1.把每个功能看做一个业务，直接用录制的脚本做基准场景和容量场景的性能测试。 2.把每个功能看做一个业务，从录制的脚本中挑出完成这个功能的核心接口做基准场景和容量场景的性能测试。 对于我设计的方案，老师能说说您的看法吗？另外，能针对我的这个需求场景，给我一些实施的建议吗？展开作者回复: 你这1和2除了静态资源之外有什么区别？ 如果静态资源线上是放在cdn上，那显然是选择2。 这个实施建议我不知道你说的是什么，这整个专栏中的都需要在实施中考虑的。像数据，业务比例，场景设计，监控设计等等。
共 3 条评论2- Geek_a55bf02022-02-11高老师好。服务性能主要是能承载的并发量的多少。而且业务间的比例是随时在变化的。那是不是取各业务的峰值来作为业务比例，然后加压到各个业务都达到峰值。如果此时能满足响应时间等指标，是不是业务比例不管如何变，只要不超过业务峰值都不会有问题
作者回复: 你这样做的话，有可能硬件资源要的比实际情况多出很多去。
1 
安静。。。2021-05-10高老师，能向您请教一下，设置比例的时候 是不是只要考虑峰值的比例就可以了，对于不是峰值的比例也不会到达服务器的瓶颈，是不是就可以不考虑了呢？作者回复: 两个关键点。 1. 业务峰值的比例。 2. 资源使用率峰值时的比例。 如果业务峰值的比例可以覆盖资源使用率峰值，那设计一个就可以了。
共 2 条评论1
09092021-03-26性能测试做的太少，看着一知半解，只能多实践，有问题再回来复习作者回复: 是需要一些知识积累。
1
勼乄児亓2020-12-24老师，有几个疑问，希望能解答: 1，业务比例我是用 控制器中的“吞吐量控制器”来控制的，这样做跟Constant Throughput Timer有什么区别吗？ 2，业务模型统计的数据，是统计接口的请求次数，还是什么？ 3，当压测环境与生产环境不是1:1时，运维大概估算一个环境比例，压测过程中，业务指标，铺底数据量也要做同比例缩放？还是铺底数据是根据存储服务网来做同比例缩放的？展开作者回复: 1，这两个控制器是完全不同的逻辑。Constant throughout Timer 只是一个定时器，它固定了指定线程在单位时间内发出去的请求数。 这个比例控制，我建议用throughout controller，它才在线程连续递增的过程中控制请求的比例。 2，看场景目标是什么，如果只是为了测试接口，那就只统计接口就可以了。如果要测试的包括静态资源，那就得都统计出来。 3，这个要先做基准测试，才能判断多少铺底数据是合理的。
1- Geek_4d71002020-07-01老师，关于生产环境和测试环境的差异如何处理呢，由于成本，很多时候生产环境和测试环境的配置不可能完全一样，鉴于这种情况，什么样的差异测试结果才有意义呢？有听说过可以做等比缩放的处理，根据硬件配置的差异，该如何界定其他指标的差异呢？
作者回复: 指标也要等比缩小才可以。但是还要看性能在递增过程中的损耗。
1 
丹2020-06-16高老师，如果正式上的服务器有十几台，测试只有1台服务器，那么这个数据是不是也要做下降级处理，比如降10倍作者回复: 看数据用在哪里了。如果存储不够可以降，如果在参数中的话其实是没有必要降的。但也有一个前提，就是硬件不够时，软件的配置是和正式环境一样的。
1
言希2020-05-31今天又翻来看一看，发现一个问题，文末中写到： 但是请注意，像 9 点业务模型中的业务 11，占比达到 30.25%；而 16 点业务模型中只有 8.69%。虽然 TPS 差不多，但是业务比例差别大，这两种业务模型下，对系统资源的消耗会完全不一样。 9点业务模型tps为333，16点业务模型为277，9点业务模型根据比例计算为不到100个，16点根据计算为不到30个，这个TPS也算差不多吗，还是说我理解错了。展开作者回复: 这里说的差不多是指总TPS。只是一个大概的说法。
1
