业务量

是不带时间单位。我们提到业务量的时候，一定会加一个时间单位。比如说，每天的业务量是 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

如有任何问题，可点击文末 阅读原文 ，到社区原文下评论交流

觉得本文有用，请转发或点击“在看”，让更多同行看到