vlambda博客
学习文章列表

性能测试中业务量、吞吐量和存量数据的设计关系

【导读】本文分析了说起来简单,但很容易被性能测试人员遗忘的问题。


业务量

是不带时间单位。我们提到业务量的时候,一定会加一个时间单位。比如说,每天的业务量是 100 万笔,每年的业务量是 1 亿笔,等等。

吞吐量

是自带时间单位的。吞吐量是单位时间内处理的业务数量。

业务量和吞吐量的关系

那么问题来了,我们做性能测试的时候,用哪个词呢?业务量 or 吞吐量?

事实上,这两个词我们都用。因为他们的内涵不同。

业务部门的目标里,往往是一年业务量多少,一天业务量多少。而这些目标并不能勾勒出性能测试目标。因为性能测试要的是每秒的业务量有多少。

举个例子,一天 24 万笔业务,并不代表一小时处理 1 万笔,也许这 24 万笔是一个小时里处理完的。

用户往往等个一两秒钟还是可以忍的,如果等 10 秒钟,恐怕是觉得系统已经挂了。因此,系统要及时处理业务请求 / 报文,不能产生严重堆积,我们最关注的是一秒钟处理多少业务。而不是一小时多少,或者一天多少。

这里有存在一个换算的过程。

业务的要求是 1 天处理 2000 万笔业务,那么吞吐量目标是多少呢?

这就要看系统的性能模型,一天当中哪个时段业务量大,这个时段的业务量占一天业务量的百分比是多少?然后一步一步的计算出峰值时期一秒钟的业务量,它,就是我们的吞吐量目标。

存量数据

有了吞吐量目标,但还不能立刻就动手做测试,这是因为,还有第三个概念,存量数据。

如果数据库是一个空库,或者数据库是个存有 2 亿条记录的库,那么 SQL 的增删改查的响应时间是完全不一样的。对应的业务响应时间也完全不一样。那么,我们数据库里面的存量数据应该设多少呢?

存量数据和业务量的关系

预计的存量数据,就要用到业务量这个概念。

毕竟,存量数据是以年、月、天为单位的,而不是以秒为单位的。

比如说,这个系统的存量数据是 3 年,或者 3 天,而不是 3 秒。

并且,计算一年的存量数据,肯定不是用峰值每秒的业务量 360024*365 来计算的。而是用到业务部门提到的业务量。

比如,今年业务量预计 100 亿笔,预计年增长率是 50% 。那么,如果要测试系统能否满足 3 年以后的需求,就要这么计算:假设系统存量数据保存 3 年,那么 3 年后的存量数据是( 100+1001.5+1001.5*1.5 )亿笔。

三年后的吞吐量这么来计算:

假设一天业务最大的那个小时,占全天业务量的 20% ,业务量最大的一秒占这个小时的 1/2000 。假设一天业务量是 A 笔。

今年的每秒吞吐量目标 B=A20%(1/2000) 。假设性能模型不变,三年后的每秒吞吐量目标 C=B1.51.5

如有任何问题,可点击文末 阅读原文 ,到社区原文下评论交流
觉得本文有用,请转发或点击“在看”,让更多同行看到


 资料/文章推荐: