06月12, 2014

通过线上数据换算性能目标值

需求与目标的确定,是性能测试过程中一项重要的前期工作,而网上关于性能目标值的推算公式已为数不少,也是各有优劣。今天就性能目标中性能指标值目标的确定根据以往的经验分享一些总结。

当确定本次性能测试的目标及测试场景后,就需要进一步确定针对该场景的指标值的目标。

性能需求常发生在一下几种情况:

  1. 业务上线一段时间产品功能已经基本稳定,用户量达到一定规模,不确定现有架构能支持多少用户量或者说能支持多久;

  2. 产品将进行推广,不确定现有架构能否支撑本次推广带来的访问量增长;

  3. 产品准备放量,需要知道业务现有架构能支撑多大规模的放量;

  4. 业务更换了一些模块,需要知道新架构的性能表现;

对于上述讨论的几种情况,针对产品均已有线上数据,我们确定性能指标的目标值,就是根据这些线上数据。

一.测试对象:

  1. 单接口

如果我们的测试对象是一个单接口,那首先需要从已有访问数据中选择一个比较稳定的单周期数据,周期数据是说,用户使用该产品的模式,在每一个周期时间内呈现一种重复的方式。对许多产品来说,用户的访问周期为一周。这与用户的工作生活方式息息相关。之所以说要选择稳定的周期数据,是因为在选择数据时要排除一些波动的异常数据,如服务器或网络发生异常时的数据;新产品上下线时段的数据;线上活动或产品放量时的数据诸如此类。

选择了一个稳定的单周期数据后,从中选择访问量最大的一天,以及这一天中访问量最高的时段,一般产品在一小时内的访问相对均匀,所以时段的长短一般选择为一小时即可。以该时段的访问量来作为该接口的性能统计最高值。但该最高值还不是我们性能测试目标值。

我们知道一般产品在每个阶段都会有不同的业务增长,所以在确定目标时还要考虑业务的增长。这就需要从相对较长的一段时间,如一年,或几个月的数据中计算该接口的访问量增幅。以上面得到的性能统计最高值为基础,并通过将访问量的增幅与用户量及活跃用户量的增幅比较,可以得到某段时间的访问量目标值,或是用户量的目标值。

  1. 场景

如果我们的测试对象是一个由几个不同接口组成的业务场景。需要注意的是,对该场景来说用户的最高访问量将是几个接口的叠加最高值,而该叠加最高值可能不是单接口的访问最高值。可能还有一种较为复杂的情况,由于场景中不同类型的接口(如读写,或者调用服务端不同模块的接口)对服务端不同组件的压力可能不同,所以整体访问量最高对服务器来说可能不代表压力最大。这事可能会有针对该场景的不同子场景的各自目标值。

二.推广策略

在一些推广或放量需求下的性能测试中,除了针对测试对象计算目标值外,还要考虑推广方式或渠道所带来的影响。

  1. 入口访问量

有些产品的推广方式是将对该产品的访问附加到另一个产品中,访问了入口产品就等于访问了推广产品。这种方式计算起来相对简单。得到了入口产品的访问量就得到了推广产品的推广目标值。再与上面得到的该产品现有的访问数据叠加即可得到目标值。

  1. 推广效果

但并非所有产品都可能以上述方式推广,另外一种方式是需用户主动访问,这就需要考虑该推广方式的效果。而一般的推广入口都会有一些历史推广数据,那么我们可以根据这些历史数据来推算推广的目标值。以及相同类型推广业务的推广效果,大概推算该业务的推广效果,即针对场景的测试对象。

三.冗余

跟据上述现有数据计算目标值后,还要通过预留一些性能冗余来保证业务在发生一些访问量突增的情况下仍能提供服务。考虑冗余基本有两种方式。

  1. 将全量用户作为活跃用户

这种方式计算较为简单。即根据上面得到的测试对象统计访问量与现有活跃用户的关系,即可换算。

  1. 冗余系数

冗余系数的考量是根据业务突发增长不会超过业务现有量的观点,所以冗余系数基本在0.5~1左右。

通过对上述三点的考量,我们最终得到了测试对象的性能目标值。

本文链接:http://blogs.360.cn/post/通过线上数据换算性能目标值.html

-- EOF --

Comments