TPS和事務響應時間的關系

例子：一個高速路有10個入口，每個入口每秒鍾只能進1輛車

1、請問1秒鍾最多能進幾輛車？

   TPS=10

2、每輛車需要多長時間進行響應？

   reponse time = 1

3、改成20輛車，每秒能進幾輛？每輛車的響應時間是多長？

   TPS = 10，reponse time = 1  (10個為一等份，分成兩等份，平均tps (10/1+10/2)/2=7.5 平均響應時間(2+1)/2=1.5

4、入口擴展到20個，每秒能進幾輛？每輛車的響應時間是多長？

   TPS = 20，reponse time = 1

5、看看，現在TPS變了，響應時間沒變，TPS和響應時間有關系嗎？

  木有關系

6、如何理解？

  TPS和響應時間在理想狀態下都是額定值(聯想運行一個壓力測試場景來考慮)，把入口看成線程池，如果有20個入口，並發數只有10的時候，TPS就是10，而響應時間始終是1，說明並發數不夠，需要增加並發數達到TPS的峰值。

7、同樣是20個入口，如果並發數變成100的話，TPS和響應時間會怎么樣呢？

  並發數到100的時候，就會出現堵車，堵車了平均每個車過去的時間就長了，把100個車按照20一份分成5份，第5份的等待時間就是最長的，從等待開始到這個車進去，實際花費了5秒，那100輛車都過去的響應時間就是（5+4+3+2+1）/5=3，平均的TPS就是（20/1+20/2+20/3+20/4+20/5)/5=9.13（我怎么感覺應該是100/（5+4+3+2+1）=6.67 完成的事務總數/完成事務數的時間，使用該方法計算出來的tps會稍微小些,可以乘以1.5倍作為當前tps）

8、由此可知，TPS和響應時間宏觀上是倒數關系，但是兩者實際上木有直接的關系的，在上例中，系統只存在20個線程，100的並發就會造成線程的等待，引起平均響應時間從1秒增加到3秒，TPS從20下降到9，TPS和響應時間都是單獨計算出來的，並不是互相算出來的！

 

9、同樣可知，在並發量保持不變的情況下，提高TPS的手段有幾種？

  A、增加線程池的數量（入口）B、降低每輛車入關的時間（也就是提高單個線程的處理效率）

 

10、從TPS和response time的定義查看這2者的區別？

  TPS = 在場景或者灰化步驟運行的每一秒鍾中，每個事務通過、失敗以及停止的次數

  也就是說，TPS = 總的通過、失敗的事務總數/整個場景的運行時間；

  reponse time = 每個事務完成實際需要的時間/事務處理數目

  因此，這2個東西壓根就是木有關系的！

 -------------------------------------------------------------------------

Jmeter聚合報告中的，吞吐量=完成的transaction數/完成這些transaction數所需要的時間；平均響應時間=所有響應時間的總和/完成的transaction數；失敗率=失敗的個數/transaction數。

性能測試中TPS的另外一種計算方法：

  在性能測試過程中，制定性能測試方案是很重要的一個環節，其中就會涉及一些指標的制定，最主要的指標是TPS（每秒處理事務數），即是用來衡量系統的處理能力的一個指標，其次就是響應時間。下面談談在實際的工作中怎么定義這兩個指標：

1、TPS指標，可以在生產環節選前一年中某個交易在某一天的最大值，然后在這一天中按分鍾為單位，列出一個時間分別表，取交易量最大的一分鍾，然后用這個交易量除以60，此時就能得TPS，然后再乘以1.5倍作為當前的TPS目標，在第二年和第三年再乘以一個1.5或2倍。

2、響應時間，根據業務的特點進行定義，插表交易一般在3秒內。

-------------------------------------------------------------------------------

TPS，每秒鍾完成的事務數

"80/20"原理：

"80/20"原理是按事情的"重要程度"編排行事優先次序的准則是建立在"重要的少數與瑣碎的多數"原理的基礎上。這個原理是十九世紀末期與二十世紀初期的意大利經濟學家兼社會學家維弗烈度·柏瑞圖所提出。它的大意是：在任何特定群體中，重要的因子通常只占少數，而不重要的因子則占多數，因此只要能控制具有重要性的少數因子即能控制全局。這個原理經過多年的演化，已變成當今管理學界所熟知的"80/20"原理--即百分之八十的價值是來自百分之二十的因子，其余的百分之二十的價值則來自百分之八十的因子.

"80/20"原理對所有人的一個重要啟示便是：避免將時間花在瑣碎的多數問題上，因為就算你花了80%的時間，你也只能取得20%的成效：你應該將時間花於重要的少數問題上，因為掌握了這些重要的少數問題，你只花20%的時間，即可取得80%的成效。

在軟件測試工作中，"80/20"原理主要應用於缺陷分布分析與性能測試需求分析。缺陷分布分析中，它指的是80%的BUG是在20%的程序代碼中發現，這其實也就是缺陷的“群集現象”。下面主要說說"80/20"原理在性能測試需求分析中的應用。

在性能測試需求分析中，"80/20"原理被這樣理解：每日80%的業務在20%的時間內完成。例如：每年業務量集中在8個月，每個月20個工作日，每個工作日8小時，即每天80%的業務量在1.6個小時內完成。

下面舉個實際的例子來看"80/20"原理的應用於性能測試需求分析。

去年全年處理業務約100萬筆，其中，15%的業務處理中，每筆業務需對應用服務器提交7次請求；70%的業務處理中，每筆業務需對應用服務器提交5次請求；其余15%的業務處理中，每筆業務需對應用服務器提交3次請求。根據以往的統計結果，每年的業務增量為15%，考慮到今后3年業務發展的需要，測試需按現有業務量得兩倍進行。

測試強度估算方法如下：

每年總的請求數為（100*15%*7+100*70%*5+100*15%*3）*2=1000萬次/年

每天的請求數為1000/(8個月*20天)=6.25萬次/天

每秒的請求數為（62500*80%）/（8小時*20%*3600秒）=8.68次/秒

即應用服務器處理請求的能力應達到9次/秒。