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

 

性能场景中的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中,业务模型跟线上的业务模型不一样的情况实在是太多了。原因可能多种多样,这些原因大大降低了性能测试的价值。

有人说,就是因为这样才应该直接用生产流量的方式来做嘛,这样就不用管业务模型了,直接就有生产的业务模型了。没错,只要你能通过生产流量扩大回放的方式实现压力部分,确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。

回放的逻辑

回放的逻辑是这样的。

 

如果你喜欢的话,还可以在每一个业务产品和基础架构的层面做接口的回放,甚至我们可以直接在数据库中回放SQL。而这些手段,都是为了模拟生产的业务模型。

这是非常容易理解的逻辑吧。

这里要批驳一个观点,就是有些人觉得只有通过生产流量回放的方式,才是真实地 模拟了线上的流量。事实上,这个观点是偏颇的。前几天有一个性能测试工程师问我一个流量回放过程中遇到的问题,谈到为什么要用流量回放。他说他们领导觉得这个最新潮最直接最正确,但实际上他得到的那段业务流量根本不能完全覆盖想测试的场景,最后折腾了一个月也是无功而返。

我知道,现在有很多人在各种场合说,可以直接在生产环境中,通过业务统计动态统计出业务场景,并实时实现到性能平台中去。这当然是一个很好的路子,但这个路子需要完整的技术实现,并且在不同的企业中,这种方式难就难在创建业务模型的统计算法,此外还要有高层领导的支持,才能真正实现完整的逻辑。

所以在今天的文章中,我想写的是最朴素的逻辑。那就是从生产数据统计,怎么转化到具体的场景中的业务模型。明白了这个逻辑之后,不管你是用生产流量回放,还是用实时业务量统计,还是线下业务量统计,你会发现原理都是一样的。

这是一个真实的案例,我已经把所有的业务名都替换掉了,同时对业务量级也做了降级调整,但这并不影响描述获取业务场景的完整性。

原系统的量级如下图所示:

 

这里我将降低10倍处理。

生产数据统计

首先我们从生产环境取出数据,粒度到秒级,取出所有业务的交易量数据。

业务量级按天统计的生成图如下:

 

我为什么要取这一段时间的数据呢?答案很简单,因为这一段时间完整地体现了这个业务系统的峰值数据

从这样的数据中取出业务量最高的一天,最大的业务量是2000万左右。

注意,我这里说的是业务量最高的一天,并不是说我们的业务场景只从这一天产生,还有别的时间,可能业务量不多,但是业务比例会完全不同,这也是要取出来的场景,所以这个统计数据到业务模型的分析过程会比较细致。我们把这一天的逻辑说完后,你就会明白其他的场景获取方式。

接着,我再以小时为单位统计出业务量比例。如下图所示:

 

从上图显然可以看出哪个小时的业务量最大,那就是9点。

但是呢,你不要忘记了,在16点的时候,明显蓝色表示的那个业务量是大于9点时的业务量的。这个也是要取出来的场景。

如果需要更细的数据,我们可以以分钟为单位看一下这个小时内的业务量分布。

 

如果你的业务有必要从分钟或秒来看的话,可以按分钟或秒来取场景比例。在我们今天的这个案例中,取到小时就已经足够。因为我要的是业务模型,而不是生产TPS量级。

另外,既然说到了这里,我再把生产TPS量级的统计说一下。有了上面的分钟统计比例,就可以很容易统计出生产环境中每个业务的最大TPS了。这里得到的TPS将是最有效的测试是否通过的SLA指标。

下面我们再以小时为单位做出百分比图。

 

为什么要做百分比图呢?因为这个比例才是我们在性能场景中设置的TPS比例,是最直接有效的比例。

业务模型计算过程

针对这一天中的数据,我们将做出以下三个业务模型。

  1. 通用业务场景模型。就是将这一天的所有业务数加在一起,再将各业务整天的交易量加在一起,计算各业务量的比例。
  2. 9点钟的业务模型。将9点钟的业务比例直接拿出来用。
  3. 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。

总结在这一篇中,我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算,只要判断出哪一段业务是我们需要的就可以了。另外我也强调了,不管用什么炫酷的手段来实现生产环境的流量模拟,最终的目标是实现和线上比较接近的业务模型。不是说一定用生产流量回放才是正确的,只有适合自己企业的手段才是最正确的。

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
性能测试模型性能测试场景设计方法可以按照以下步骤进行: 1. 确定测试目标和需求:首先,明确性能测试的目标和需求。确定要测试的系统、应用程序或服务的性能指标,例如响应时间、吞吐量、并发用户数等。 2. 收集系统信息:了解被测试系统的架构、硬件配置、软件配置以及网络环境等信息。这些信息将有助于确定测试场景和设计合适的负载模型。 3. 识别关键业务场景:根据系统的功能和用户行为,识别出关键的业务场景。这些场景应该代表了系统最常见、最重要的使用情况,以确保测试的真实性和有效性。 4. 设计负载模型:根据收集到的系统信息和识别出的关键业务场景,设计合适的负载模型。负载模型包括并发用户数、请求频率、数据量等,用来模拟真实世界中的用户行为。 5. 设置环境和工具:搭建测试环境,并选择合适的性能测试工具。测试环境应该与生产环境尽可能相似,以保证测试结果的准确性。 6. 编写脚本和配置:根据负载模型和测试工具的要求,编写测试脚本和配置。脚本应该能够模拟用户的行为,并生成相应的负载。 7. 执行测试:根据设计的测试场景和负载模型,执行性能测试。监控系统的性能指标,记录测试结果。 8. 分析结果:根据测试结果,分析系统的性能表现。比较实际性能与预期性能,找出性能瓶颈和优化空间。 9. 提出建议:根据性能测试的结果和分析,提出改进系统性能的建议和措施。这些建议可以包括优化代码、调整系统配置、增加硬件资源等。 总结来说,基于性能测试模型性能测试场景设计方法包括确定目标和需求、收集系统信息、识别关键业务场景、设计负载模型、设置环境和工具、编写脚本和配置、执行测试、分析结果以及提出建议。这个方法可以帮助确保性能测试的有效性和准确性,并为系统的性能优化提供指导。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值