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，那麼這個系統的日吞吐量=100113600=396萬

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

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

併發數、QPS、平均響應時間三者之間關係

系統吞吐量評估方法

軟體效能測試的基本概念和計算公式

一、軟體效能的關注點

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

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

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

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

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

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

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=uCT/VU
• D、根據公式計算出思考時間
  TS=T/R