業務量：是不帶時間單位。我們提到業務量的時候，一定會加一個時間單位。比如說，每天的業務量是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