性能測試入門（一）性能測試之QPS、TPS、併發量、系統吞吐量的概念

QPS: 每秒鐘處理完請求的次數；具體是指發出請求到服務器處理完成功返回結果。

TPS：每秒鐘處理完的事務次數，通常TPS是對整個系統來說的。一個應用系統1s能完成多少事務處理，一個事務在分佈式處理中，可能會對應多個請求，對於衡量單個接口服務的處理能力，用QPS比較多。

併發量：系統能同時處理的請求數

RT：響應時間，處理一次請求所須要的平均處理時間

計算關係：

  QPS = 併發量 / 平均響應時間

  併發量 = QPS * 平均響應時間

 

TPS: （每秒事務處理量(TransactionPerSecond)）

一個表達系統處理能力的性能指標，每秒處理的消息數（Transaction Per Second）,
每秒事務處理量 - 性能測試的術語介紹
每秒鐘系統可以處理的交易或事務的數量。它是衡量系統處理能力的重要指標。TPS是LoadRunner中重要的性能參數指標。
一個事務是指一個客戶機向服務器發送請求而後服務器作出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數

 

過程包括：

客戶端請求服務端
服務端內部處理
服務端返回客戶端

QPS:每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
每秒查詢率:

因特網上，常常用每秒查詢率來衡量域名系統服務器的機器的性能，其即爲QPS。
對應fetches/sec，即每秒的響應請求數，也便是最大吞吐能力。
計算關係：
QPS = 併發量 / 平均響應時間
併發量 = QPS * 平均響應時間

Qps基本相似於Tps，可是不一樣的是，對於一個頁面的一次訪問，造成一個Tps；但一次頁面請求，可能產生屢次對服務器的請求，服務器對這些請求，就可計入「Qps」之中

例：訪問一個頁面會請求服務器3次，一次放，產生一個「T」，產生3個「Q」

文章參考：https://blog.csdn.net/zuoanyinxiang/article/details/51252049

 

轉自：https://www.cnblogs.com/cynchanpin/p/7365859.html

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

一．系統吞度量要素：

  一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢。系統吞吐能力越低，反之越高。

系統吞吐量幾個重要參數：QPS（TPS）、併發數、響應時間

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

        併發數： 系統同一時候處理的request/事務數

        響應時間：  通常取平均響應時間

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

理解了上面三個要素的意義以後，就能推算出它們之間的關係：
QPS（TPS）= 併發數/平均響應時間    或者   併發數 = QPS*平均響應時間

        一個典型的上班簽到系統，早上8點上班。7點半到8點這30分鐘的時間裏用戶會登陸簽到系統進行簽到。公司員工爲1000人，平均每個員上登陸簽到系統的時長爲5分鐘。可以用如下的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間爲 = 5*60  秒
併發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7

        一個系統吞吐量一般由QPS（TPS）、併發數兩個因素決定，每套系統這兩個值都有一個相對極限值。在應用場景訪問壓力下，僅僅要某一項達到系統最高值。系統的吞吐量就上不去了，假設壓力繼續增大。系統的吞吐量反而會降低。緣由是系統超負荷工做，上下文切換、內存等等其餘消耗致使系統性能降低。

 

決定系統響應時間要素

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

系統一次調用的響應時間跟項目計劃同樣，也有一條關鍵路徑，這個關鍵路徑是就是系統響應時間。

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

二．系統吞吐量評估：

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

而一般境況下，咱們面對需求，咱們評估出來的出來QPS、併發數以外，還有另一個維度：日PV。

 

經過觀察系統的訪問日誌發現。在用戶量很是大的狀況下，各個時間週期內的同一時間段的訪問流量差點兒同樣。比方工做日的天天早上。僅僅要能拿到日流量圖和QPS咱們就可以推算日流量。

 

一般的技術方法：

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

        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、平均響應時間三者之間關係

   上圖橫座標是併發用戶數。

綠線是CPU使用率。紫線是吞吐量，即QPS。藍線是時延。
    開始，系統僅僅有一個用戶，CPU工做確定是不飽合的。一方面該server可能有多個cpu，但是僅僅處理單個進程。還有一方面，在處理一個進程中，有些階段多是IO階段，這個時候會形成CPU等待，但是有沒有其它請 求進程能夠被處理）。

隨着併發用戶數的添加，CPU利用率上升。QPS對應也添加（公式爲QPS=併發用戶數/平均響應時間。）隨着併發用戶數的添加。平均響應時間也在添加。而且平均響應時間的添加是一個指數添加曲線。而當併發數添加到很是大時，每秒鐘都會有很是多請求需要處理。會形成進程（線程）頻繁切換。反正真正用於處理請求的時間變少，每秒能夠處 理的請求數反而變少。同一時候用戶的請求等待時間也會變大。甚至超過用戶的心理底線。

來源：http://www.cnblogs.com/jackei/

軟件性能測試的基本概念和計算公式

1、軟件性能的關注點

對一個軟件作性能測試時需要關注那些性能呢？

咱們想一想在軟件設計、部署、使用、維護中一共同擁有哪些角色的參與。而後再考慮這些角色各自關注的性能點是什麼，做爲一個軟件性能測試project師。咱們又該關注什麼？

首先。開發軟件的目的是爲了讓用戶使用，咱們先站在用戶的角度分析一下，用戶需要關注哪些性能。

對於用戶來講，當點擊一個button、連接或發出一條指令開始，到系統把結果已用戶感知的形式展示出來爲止。這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。

也就是咱們所說的響應時間，當對應時間較小時，用戶體驗是很是好的，固然用戶體驗的響應時間包含我的主觀因素和客觀響應時間，在設計軟件時，咱們就需要考慮到怎樣更好地結合這兩部分達到用戶最佳的體驗。

如：用戶在大數據量查詢時，咱們可以將先提取出來的數據展現給用戶，在用戶看的過程當中繼續進行數據檢索，這時用戶並不知道咱們後臺在作什麼。

 

用戶關注的是用戶操做的對應時間。

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

一、 對應時間
二、 server資源使用狀況是否合理
三、 應用server和數據庫資源使用是否合理
四、 系統是否能實現擴展
五、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
六、 系統性能可能存在的瓶頸在哪裏
七、 更換那些設備可以提升性能
八、 系統是否能支持7×24小時的業務訪問

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

 

一、 架構設計是否合理
二、 數據庫設計是否合理
三、 代碼是否存在性能方面的問題
四、 系統中是否有不合理的內存使用方式
五、 系統中是否存在不合理的線程同步方式
六、 系統中是否存在不合理的資源競爭

那麼站在性能測試project師的角度，咱們要關注什麼呢？

一句話。咱們要關注以上所有的性能點。

2、軟件性能的幾個主要術語

一、響應時間：對請求做出響應所需要的時間

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

應用server處理時間：A1+A3

數據庫server處理時間：A2

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

二、併發用戶數的計算公式

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

 

同一時候在線用戶數：在必定的時間範圍內。最大的同一時候在線用戶數量。
同一時候在線用戶數=每秒請求數RPS（吞吐量）+併發鏈接數+平均用戶思考時間

平均併發用戶數的計算：C=nL / T

當中C是平均的併發用戶數，n是平均天天訪問用戶數（login session），L是一天內用戶從登陸到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間實用戶使用系統）

併發用戶數峯值計算：C^約等於C + 3*根號C

當中C^是併發用戶峯值。C是平均併發用戶數。該公式遵循泊松分佈理論。

三、吞吐量的計算公式

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

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

從網絡角度看，吞吐量可以用：字節/秒來衡量

對於交互式應用來講。吞吐量指標反映的是server承受的壓力，他能夠說明系統的負載能力

以不一樣方式表達的吞吐量可以說明不一樣層次的問題，好比。以字節數/秒方式可以表示數要受網絡基礎設施、server架構、應用server制約等方面的瓶頸。已請求數/秒的方式表示主要是受應用server和應用代碼的制約體現出的瓶頸。

 

當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在必定的聯繫。可以採用下面公式計算：F=VU * R /

當中F爲吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間

四、性能計數器

是描寫敘述server或操做系統性能的一些數據指標。如使用內存數、進程時間。在性能測試中發揮着「監控和分析」的做用，尤爲是在分析通通可擴展性、進行新能瓶頸定位時有着很關鍵的做用。

 

資源利用率：指系統各類資源的使用狀況，如cpu佔用率爲68%，內存佔用率爲55%，通常使用「資源實際使用/總的資源可用量」造成資源利用率。

 

五、思考時間的計算公式

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