性能场景中的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中，业务模型跟线上的业务模型不一样的情况实在是太多了。原因可能多种多样，这些原因大大降低了性能测试的价值。
有人说，就是因为这样才应该直接用生产流量的方式来做嘛，这样就不用管业务模型了，直接就有生产的业务模型了。没错，只要你能通过生产流量扩大回放的方式实现压力部分，确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。
回放的逻辑
回放的逻辑是这样的。
如果你喜欢的话，还可以在每一个业务产品和基础架构的层面做接口的回放，甚至我们可以直接在数据库中回放SQL。而这些手段，都是为了模拟生产的业务模型。
这是非常容易理解的逻辑吧。
这里要批驳一个观点，就是有些人觉得只有通过生产流量回放的方式，才是真实地 模拟了线上的流量。事实上，这个观点是偏颇的。前几天有一个性能测试工程师问我一个流量回放过程中遇到的问题，谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确，但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景，最后折腾了一个月也是无功而返。
我知道，现在有很多人在各种场合说，可以直接在生产环境中，通过业务统计动态统计出业务场景，并实时实现到性能平台中去。这当然是一个很好的路子，但这个路子需要完整的技术实现，并且在不同的企业中，这种方式难就难在创建业务模型的统计算法，此外还要有高层领导的支持，才能真正实现完整的逻辑。
所以在今天的文章中，我想写的是最朴素的逻辑。那就是从生产数据统计，怎么转化到具体的场景中的业务模型。明白了这个逻辑之后，不管你是用生产流量回放，还是用实时业务量统计，还是线下业务量统计，你会发现原理都是一样的。
这是一个真实的案例，我已经把所有的业务名都替换掉了，同时对业务量级也做了降级调整，但这并不影响描述获取业务场景的完整性。
原系统的量级如下图所示：
这里我将降低10倍处理。
生产数据统计
首先我们从生产环境取出数据，粒度到秒级，取出所有业务的交易量数据。
业务量级按天统计的生成图如下：
我为什么要取这一段时间的数据呢？答案很简单，因为这一段时间完整地体现了这个业务系统的峰值数据。
从这样的数据中取出业务量最高的一天，最大的业务量是2000万左右。
注意，我这里说的是业务量最高的一天，并不是说我们的业务场景只从这一天产生，还有别的时间，可能业务量不多，但是业务比例会完全不同，这也是要取出来的场景，所以这个统计数据到业务模型的分析过程会比较细致。我们把这一天的逻辑说完后，你就会明白其他的场景获取方式。
接着，我再以小时为单位统计出业务量比例。如下图所示：
从上图显然可以看出哪个小时的业务量最大，那就是9点。
但是呢，你不要忘记了，在16点的时候，明显蓝色表示的那个业务量是大于9点时的业务量的。这个也是要取出来的场景。
如果需要更细的数据，我们可以以分钟为单位看一下这个小时内的业务量分布。
如果你的业务有必要从分钟或秒来看的话，可以按分钟或秒来取场景比例。在我们今天的这个案例中，取到小时就已经足够。因为我要的是业务模型，而不是生产TPS量级。
另外，既然说到了这里，我再把生产TPS量级的统计说一下。有了上面的分钟统计比例，就可以很容易统计出生产环境中每个业务的最大TPS了。这里得到的TPS将是最有效的测试是否通过的SLA指标。
下面我们再以小时为单位做出百分比图。
为什么要做百分比图呢？因为这个比例才是我们在性能场景中设置的TPS比例，是最直接有效的比例。
业务模型计算过程
针对这一天中的数据，我们将做出以下三个业务模型。
- 通用业务场景模型。就是将这一天的所有业务数加在一起，再将各业务整天的交易量加在一起，计算各业务量的比例。
- 9点钟的业务模型。将9点钟的业务比例直接拿出来用。
- 16点的业务模型。将16点钟的业务比例直接拿出来用。
首先我们看一下通用业务模型。
我们将上面的0%的业务全部删除，再计算一次百分比，得到测试场景中的业务比例。如下所示：
做为最基础的业务比例，这个可以覆盖大部分的业务时间了。
在通用的业务场景中，如果业务团队有给出明确的TPS指标，那就有依赖了。但是，如果没有给的话，也不要气馁。我们可以根据系统的运行时段，计算平均值即可。
因为我们这个系统是24小时系统，所以我用24小时来计算。得到如下值：
$TPS1 = \frac{20000000}{24*3600} = 231$
也就是说通用场景中，TPS不能低于231。
接着我们看下9点的业务模型。计算方法和上面一样，最后得出比例。
我们可以从小时图中看到，9点的业务量总和有120万左右。为了方便，这里我拿120万来计算。它的生产TPS就是：1,200,000 / 3600 = 333。
$TPS2 = \frac{1200000}{3600} = 333$
显然，这个模型下做场景时就不能低于333TPS。
最后看一下16点的业务场景。
从小时图中，我们可以看到，16点的业务量总和有100万左右。为了方便，这里我拿100万来计算。它的生产TPS就是：
$TPS3 = \frac{1,000,000}{3600} = 277$
显然，这个模型下做场景时就不能低于277TPS。
但是请注意，像9点业务模型中的业务11，占比达到30.25%；而16点业务模型中只有8.69%。虽然TPS差不多，但是业务比例差别大，这两种业务模型下，对系统资源的消耗会完全不一样。
最后我稍微说一下TPS的控制。
有了这个计算过程，当我们把这些比例设计到场景中去的时候，一定要注意这些TPS的比例在运行过程中，不能发生大的变化。一旦压力发起后，由于各业务的响应时间随着压力的增加发生的变化量不同，就会导致运行过程中业务比例出现很大的偏差。
我们做性能测试工程师的，都有过这样的经历。通常，在LoadRunner里，会用pacing来控制TPS，而用JMeter的，则会用Constant Throughput Timer来控制TPS。
总结
在这一篇中，我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算，只要判断出哪一段业务是我们需要的就可以了。
另外我也强调了，不管用什么炫酷的手段来实现生产环境的流量模拟，最终的目标是实现和线上比较接近的业务模型。不是说一定用生产流量回放才是正确的，只有适合自己企业的手段才是最正确的。
问题
那么最后给你留两个问题，为什么业务比例对性能场景如此重要？以及如何在执行场景过程中控制TPS比例呢？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
精选留言
2020-11-06 17:58:39
业务比例一般都是从生产数据统计来的，设置这样的比例能够更真实地模拟生产流量模型
2、如何在执行场景过程中控制 TPS 比例呢？
以jmeter为例，我们使用的是Throughput Shaping Timer和Weighted Switch Controller这两个插件。Weighted Switch Controller是比例控制器，控制的是压力的比例，其实也是控制了TPS的比例了，这个时候随着线程数增加，TPS一般会往上增加直到达到最大TPS。另外，我们还会使用控制接口最大TPS的方式去压，这个时候就会用到Throughput Shaping Timer，这个是控制接口最大TPS的元件，如果多个接口都在一个线程组里面的话，需要和比例控制器一起使用，如果在不同的线程组，则不需要
2020-09-16 22:49:15
2020-01-15 13:06:37
2020-02-20 16:44:59
1.用业务比例来进行容量测试时，用Constant Throughput Timer控制了tps，是不是就压不到最大值了，受限于所设置的tps值，觉得这里设置的tps和想要得到的最大TPS值冲突了
2.用业务比例来进行容量测试时，是不是需要同时使用吞吐量控制器（来控制业务的百分比）和常数吞吐量定时器（控制总TPS），如果不是，那应该怎么实现呢。
2020-01-17 12:45:48
不同的业务对系统资源的消耗完全不一样，如果业务比例跟实际的业务比例不一样，就会导致运行过程中资源消耗出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
另外，如果生产流量来源是可以覆盖想要测试的业务场景的，可以通过生产流量扩大回放的方式实现压力部分，就不用考虑业务场景了。
2.如何在执行场景过程中控制 TPS 比例呢？
通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。注意，JMeter中，Throughput Controller并不控制TPS。
另外请教老师，根据业务模型推算出各业务的TPS，从而根据公式，结合响应时间推算出压力机线程数。这个思路对吗？如果对，如何进一步确定压力机线程数配置，具体来说，问题1，响应时间怎么获取？是业务提出的，还是基准测试中获得的最大TPS对应的响应时间？问题2，推算出来的压力机线程数就是测试中的最大值吗？是否需要适当加大一些呢？如果需要，增加多少合适？如果不是测试中的最大值，怎么取值？问题3，在一次场景测试中，业务模型是一直要保持吗？比如说，起始线程数的配置也是要按业务比例计算吗？中间任一时刻都得按业务比例设计吗？
2022-05-10 15:36:07
2020-07-22 12:52:22
2020-06-20 21:48:48
2020-04-26 17:41:18
2020-04-04 23:16:50
高老师，请教下：业务比例是针对系统的所有业务给出来的，但实际压测，并不是要压测所有的业务，例如，系统有4个业务分别为A、B、C、D，他们的业务比例分别为40%、30%、20%、10%，假如本次压测是业务B、C，A和D不做压测，那容量测试的业务比例是设置合适呢
2020-01-21 15:20:15
2021-08-06 13:43:03
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.专栏中的接口该怎么理解，接口对应哪个级别的事务？
2021-05-10 15:06:30
2020-12-24 16:01:08
1，业务比例我是用 控制器中的“吞吐量控制器”来控制的，这样做跟Constant Throughput Timer有什么区别吗？
2，业务模型统计的数据，是统计接口的请求次数，还是什么？
3，当压测环境与生产环境不是1:1时，运维大概估算一个环境比例，压测过程中，业务指标，铺底数据量也要做同比例缩放？还是铺底数据是根据存储服务网来做同比例缩放的？
2020-06-16 13:57:00
2020-03-01 10:10:49
2020-01-15 08:32:55
2022-02-11 09:24:29
2021-02-20 22:18:43
2020-07-01 18:47:23