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次/秒。

PS：下面是效能測試的主要概念和計算公式，記錄下：

一．系統吞度量要素：

  一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。

單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。

系統輸送量幾個重要參數：QPS（TPS）、並發數、回應時間

        QPS（TPS）：每秒鐘request/事務 數量

        並發數： 系統同時處理的request/事務數

        回應時間：  一般取平均回應時間

（很多人經常會把並發數和TPS理解混淆）

理解了上面三個要素的意義之後，就能推算出它們之間的關係：

QPS（TPS）= 並發數/平均回應時間

        一個系統輸送量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用情境訪問壓力下，只要某一項達到系統最高值，系統的輸送量就上不去了，如果壓力繼續增大，系統的輸送量反而會下降，原因是系統超負荷工作，環境切換、記憶體等等其它消耗導致系統效能下降。

決定系統回應時間要素

我們做項目要排計劃，可以多人同時並發做多項任務，也可以一個人或者多個人串列工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。

系統一次調用的回應時間跟專案計劃一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；

關鍵路徑是有CPU運算、IO、外部系統響應等等組成。

二．系統輸送量評估：

我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統效能的初步預估。

而通常境況下，我們面對需求，我們評估出來的出來QPS、並發數之外，還有另外一個維度：日PV。

通過觀察系統的訪問日誌發現，在使用者量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和QPS我們就可以推算日流量。

通常的技術方法：

        1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關係（除了放假、季節性因素影響之外）

        2. 通過壓力測試或者經驗預估，得出最高TPS，然後跟進1的關係，計算出系統最高的日輸送量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網路行為不應用，他們之間的TPS和PV關係比例也不一樣。

A)淘寶

淘寶流量圖：

淘寶的TPS和PV之間的關係通常為  最高TPS：PV大約為 1 : 11*3600 （相當於按最高TPS訪問11個小時，這個是商品詳情的情境，不同的應用情境會有一些不同）

B) B2B中文站

B2B的TPS和PV之間的關係不同的系統不同的應用情境比例變化比較大，粗數量級估計在1 : 8個小時左右的關係（09年對offerdetail的流量分析資料）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。

在淘寶環境下，假設我們壓力測試出的TPS為100，那麼這個系統的日輸送量=100*11*3600=396萬

這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際輸送量還要小。

無論有無考慮時間（T_think），測試所得的TPS值和並發虛擬使用者數(U_concurrent)、Loadrunner讀取的交易回應時間（T_response）之間有以下關係（穩定運行情況下）：
TPS=U_concurrent / (T_response+T_think)。

並發數、QPS、平均回應時間三者之間關係

來源：http://www.cnblogs.com/jackei/ 軟體效能測試的基本概念和計算公式

一、軟體效能的關注點

對一個軟體做效能測試時需要關注那些效能呢。

我們想想在軟體設計、部署、使用、維護中一共有哪些角色的參與，然後再考慮這些角色各自關注的效能點是什麼，作為一個軟體效能測試工程師，我們又該關注什麼。

首先，開發軟體的目的是為了讓使用者使用，我們先站在使用者的角度分析一下，使用者需要關注哪些效能。

對於使用者來說，當點擊一個按鈕、連結或發出一條指令開始，到系統把結果已使用者感知的形式展現出來為止，這個過程所消耗的時間是使用者對這個軟體效能的直觀印象。也就是我們所說的回應時間，當相應時間較小時，使用者體驗是很好的，當然使用者體驗的回應時間包括個人主觀因素和客觀回應時間，在設計軟體時，我們就需要考慮到如何更好地結合這兩部分達到使用者最佳的體驗。如：使用者在大資料量查詢時，我們可以將先提取出來的資料展示給使用者，在使用者看的過程中繼續進行資料檢索，這時使用者並不知道我們後台在做什麼。

使用者關注的是使用者操作的相應時間。

其次，我們站在管理員的角度考慮需要關注的效能點。

1、 相應時間
2、 伺服器資源使用方式是否合理
3、 應用伺服器和資料庫資源使用是否合理
4、 系統能否實現擴充
5、 系統最多支援多少使用者訪問、系統最大業務處理量是多少
6、 系統效能可能存在的瓶頸在哪裡
7、 更換那些裝置可以提高效能
8、 系統能否支援7×24小時的業務訪問

再次，站在開發（設計）人員角度去考慮。

1、 架構設計是否合理
2、 資料庫設計是否合理
3、 代碼是否存在效能方面的問題
4、 系統中是否有不合理的記憶體使用量方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭

那麼站在效能測試工程師的角度，我們要關注什麼呢。

一句話，我們要關注以上所有的效能點。

二、軟體效能的幾個主要術語

1、回應時間：對請求作出響應所需要的時間

網路傳輸時間：N1+N2+N3+N4

應用伺服器處理時間：A1+A3

資料庫伺服器處理時間：A2

回應時間=N1+N2+N3+N4+A1+A3+A2

2、並發使用者數的計算公式

系統使用者數：系統額定的使用者數量，如一個OA系統，可能使用該系統的使用者總數是5000個，那麼這個數量，就是系統使用者數。

同時線上使用者數：在一定的時間範圍內，最大的同時線上使用者數量。
同時線上使用者數=每秒請求數RPS（輸送量）+並發串連數+平均使用者考慮時間

平均並發使用者數的計算：C=nL / T

其中C是平均的並發使用者數，n是平均每天訪問使用者數（login session），L是一天內使用者從登入到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有使用者使用系統）

並發使用者數峰值計算：C^約等於C + 3*根號C

其中C^是並發使用者峰值，C是平均並發使用者數，該公式遵循泊松分布理論。

3、輸送量的計算公式

指單位時間內系統處理使用者的請求數

從業務角度看，輸送量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量

從網路角度看，輸送量可以用：位元組/秒來衡量

對於互動式應用來說，輸送量指標反映的是伺服器承受的壓力，他能夠說明系統的負載能力

以不同方式表達的輸送量可以說明不同層次的問題，例如，以位元組數/秒方式可以表示數要受網路基礎設施、伺服器架構、應用伺服器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用伺服器和應用代碼的制約體現出的瓶頸。

當沒有遇到效能瓶頸的時候，輸送量與虛擬使用者數之間存在一定的聯絡，可以採用以下公式計算：F=VU * R /

其中F為輸送量，VU表示虛擬使用者個數，R表示每個虛擬使用者發出的請求數，T表示效能測試所用的時間

4、效能計數器

是描述伺服器或作業系統效能的一些資料指標，如使用記憶體數、進程時間，在效能測試中發揮著“監控和分析”的作用，尤其是在分析統統可擴充性、進行新能瓶頸定位時有著非常關鍵的作用。

資源使用率：指系統各種資源的使用方式，如cpu佔用率為68%，記憶體佔用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源使用率。

5、考慮時間的計算公式

Think Time，從業務角度來看，這個時間指使用者進行操作時每個請求之間的時間間隔，而在做新能測試時，為了類比這樣的時間間隔，引入了考慮時間這個概念，來更加真實的類比使用者的操作。

在輸送量這個公式中F=VU * R / T說明輸送量F是VU數量、每個使用者發出的請求數R和時間T的函數，而其中的R又可以用時間T和使用者考慮時間TS來計算：R = T / TS

下面給出一個計算考慮時間的一般步驟：

A、首先計算出系統的並發使用者數

C=nL / T F=R×C

B、統計出系統平均的輸送量

F=VU * R / T R×C = VU * R / T

C、統計出平均每個使用者發出的請求數量

R=u*C*T/VU

D、根據公式計算出考慮時間

TS=T/R