下载APP
关闭
讲堂
部落
算法训练营
前端进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
14丨性能测试场景：如何理解业务模型？
2020-01-15 高楼
性能测试实战30讲
进入课程
讲述：高楼
时长12:14大小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 比例呢？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
13丨性能测试场景：如何进行场景设计？
下一篇
15丨性能测试场景：如何进行监控设计？
写留言
精选留言(13)
2020-01-16老师，您好。我是一名性能测试小白，想请教您一个问题。在做性能测试时，如何理解和定义业务？是实现这个业务逻辑的核心接口，还是完成这个业务操作所涉及到的所有接口？比如，我们目前打算上线一款APP，我想做一下接口的性能测试，评估服务器目前的承载能力，为后期服务器规划扩容提供数据支撑。由于目前没有实际的生产流量，因此我根据APP的特点，站在用户的角度分功能操作APP并用JMeter录制脚本，于是我设计了两个测试方案：
1.把每个功能看做一个业务，直接用录制的脚本做基准场景和容量场景的性能测试。
2.把每个功能看做一个业务，从录制的脚本中挑出完成这个功能的核心接口做基准场景和容量场景的性能测试。
对于我设计的方案，老师能说说您的看法吗？另外，能针对我的这个需求场景，给我一些实施的建议吗？展开作者回复: 你这1和2除了静态资源之外有什么区别？
如果静态资源线上是放在cdn上，那显然是选择2。
这个实施建议我不知道你说的是什么，这整个专栏中的都需要在实施中考虑的。像数据，业务比例，场景设计，监控设计等等。 2- 2020-01-15高老师，有哪些好用的工具可以辅助分析业务比例么？文中的比例图是怎么画出来的呀？
作者回复: elk就可以分析呀。比例图用excel就能画。
1 2 
2020-01-21高老师，请问业务数据是怎么统计出来的？展开作者回复: 生产日志统计来的。
2020-01-19Elk分析业务比例具体细节想了解一下展开作者回复: 这个直接统计就好了吧。ELK中有图可以生成，有时间段，有业务量的。
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比例的一致性。- 2020-01-16老师讲的以tps来承载业务比例，和jmeter中按if控制器来配置不同业务的请求比例，很容易引起混淆。希望老师能澄清下这两个的区别。展开
作者回复: if控制器不能控制业务的请求比例呀。 我没有写if控制器哦。
- 2020-01-16刚好拿到了一个项目高峰期间的ng日志，正好可以按老师说的实践分析下啦。然后和项目上线前的预估比例和指标进行对比看看偏差。展开
作者回复: 做下看看结果。会感觉很有意思的。
- 2020-01-16问题一:首先只有混合容量性能测试场景下得出的tps才是最接近服务器能承载的最大或者说最佳容量，而混合容量场景却需要由事先确认好的业务比例来保证这个场景是有效的，最接近线上业务的。
问题二:我有个疑问，当我们使用Constant Throughput Timer时，肯定是需要事先设置好并发数的，我曾经试过在相同的请求数下，不同的线程数在刚开始跑的时候tps波动不一致，也就是说线程数越大，tps也越大，只不过随着时间推移慢慢接近设置的tps。而设置小的线程数整体的tps确实很平坦的。
还有就是老师这一次也没见您说递增式的场景？按我理解，无论是单交易还是混合容量，在压测时不应该都用递增式来逐渐达到最大tps吗？
请老师点评以及回答展开作者回复: 递增是所有场景的默认条件。我觉得前面已经强调的够重了。😃😃
2020-01-15每上线一个新系统就要求压压看，然后这时候是没有什么业务峰值的，就根据当前配置代码做个压测得出最大TPS，那么这里说到没根据生产业务模型是没意义的？还有必要做吗作者回复: 你这个也就是扫扫上了压力就出现的明显bug，其他没什么用。
1
2020-01-15高老师，看完文章有两个疑问：1 . 在jmeter中，业务比例是依靠什么承载的，是线程数吗？A业务占百分之八十，我就设置A为百分之八十的线程数吗？ 2. 那种按照一小时取平均tps 是不是太粗糙？ 比如 虽然一小时 是2000万的业务量，但是其中的1000万的业务量是在最高峰的10分钟产生的，高峰的tps其实是16000，展开作者回复: 根据tps承载比例。
2020-01-15Elk分析业务比例具体细节能介绍下吗展开作者回复: 暂时没有计划说这一块的内容。等后期全部更新完毕之后，如果有更多人询问这个问题。再考虑是否加餐。
2020-01-15答：
1、通过对生产数据统计能够完整体现系统业务的峰值数据，然后转换成具体场景中的业务模型，模拟真实的生产环境中的业务比例。不同的业务对系统资源的消耗完全不一样，如果业务模型跟线上的业务模型不一样，就会导致运行过程中业务比例出现很大的偏差，那么得到的结果不够真实正确，也大大降低了性能测试的价值。
2、执行场景中控制TPS比例的方法： LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。展开作者回复: 看来是理解了。
- 2020-01-15第一个问题我认为业务比例越趋近生产环境得到的性能数据越真实，生产流量的回放我理解的核心目的也是为了真实的覆盖所需要测试的性能场景，如果业务比例跟真实环境差距很大，那么得到的数据是没有意义的
第二个问题控制TPS比例需要根据线上的统计得到每个服务TPS的峰值及范围，不同的天数和时段TPS是不同的，需要根据线上的TPS的比例去测试系统的资源占用和性能指标，这样才能够真实的反应系统的性能情况，不论做系统当前性能测试还是未来系统的容量规划都是有意义的展开作者回复: 理解的很对。
