业务量：是不带时间单位。我们提到业务量的时候，一定会加一个时间单位。比如说，每天的业务量是100万笔，每年的业务量是1亿笔，等等
吞吐量，是自带时间单位的。吞吐量是单位时间内处理的业务数量。
业务量和吞吐量的关系？
那么问题来了，我们做性能测试的时候，用哪个词呢？业务量 or 吞吐量？
事实上，这两个词我们都用。因为它们的内涵不同。
业务部门的目标里，往往是一年业务量多少，一天业务量多少。而这些目标并不能勾勒出性能测试目标。因为性能测试要的是每秒的业务量有多少。
举个例子，一天24万笔业务，并不代表一小时处理1万笔，也许这24万笔是一个小时里处理完的。
用户往往等个一两秒钟还是可以忍的，如果等10秒钟，恐怕是觉得系统已经挂了。因此，系统要及时处理业务请求/报文，不能产生严重堆积，我们最关注的是一秒钟处理多少业务。而不是一小时多少，或者一天多少。
这里有存在一个换算的过程
业务的要求是1天处理2000万笔业务，那么吞吐量目标是多少呢？
这就要看系统的性能模型，一天当中哪个时段业务量大，这个时段的业务量占一天业务量的百分比是多少？然后一步一步的计算出峰值时期一秒钟的业务量，它——就是我们的吞吐量目标。
存量数据，有了吞吐量目标，但还不能立刻就动手做测试，这是因为，还有第三个概念，存量数据。
如果数据库是一个空库，或者数据库是个存有2亿条记录的库，那么SQL的增删改查的响应时间是完全不一样的。对应的业务响应时间也完全不一样。那么，我们数据库里面的存量数据应该设多少呢？
存量数据和业务量的关系
预计的存量数据，就要用到业务量这个概念。
毕竟，存量数据是以年、月、天为单位的，而不是以秒为单位的。
比如说，这个系统的存量数据是3年，或者3天，而不是3秒。
并且，计算一年的存量数据，肯定不是用峰值每秒的业务量*3600*24*365来计算的。而是用到业务部门提到的业务量。
比如，今年业务量预计100亿笔，预计年增长率是50%。那么，如果要测试系统能否满足3年以后的需求，就要这么计算：假设系统存量数据保存3年，那么3年后的存量数据是（100+100*1.5+100*1.5*1.5）亿笔。
三年后的吞吐量这么来计算：
假设一天业务最大的那个小时，占全天业务量的20%，业务量最大的一秒占这个小时的1/2000。假设一天业务量是A笔。
今年的每秒吞吐量目标B=A*20%*(1/2000)。假设性能模型不变，三年后的每秒吞吐量目标C=B*1.5*1.5