併發用戶數與 TPS 之間的關係 | 系統吞吐量、TPS（QPS）、用戶併發量、性能測試概念和公式

時間 2020-07-22

標籤併發戶數 tps 之間關係系統吞吐量 qps 用戶性能測試概念公式欄目系統性能简体版

原文原文鏈接

1. 背景

在作性能測試的時候，不少人都用併發用戶數來衡量系統的性能，以爲系統能支撐的併發用戶數越多，系統的性能就越好；對TPS不是很是理解，也根本不知道它們之間的關係，所以很是有必要進行解釋。 html

2. 術語定義

Ø 併發用戶數：指的是現實系統中操做業務的用戶，在性能測試工具中，通常稱爲虛擬用戶數(Virutal User)，注意併發用戶數跟註冊用戶數、在線用戶數有很大差異的，併發用戶數必定會對服務器產生壓力的，而在線用戶數只是」掛」在系統上，對服務器不產生壓力，註冊用戶數通常指的是數據庫中存在的用戶數。數據庫

Ø TPS：Transaction Per Second, 每秒事務數, 是衡量系統性能的一個很是重要的指標，服務器

3. Vu和TPS換算

Ø 簡單例子：在術語中解釋了TPS是每秒事務數，可是事務時要靠虛擬用戶作出來的，假如1個虛擬用戶在1秒內完成1筆事務，那麼TPS明顯就是1；若是某筆業務響應時間是1ms,那麼1個用戶在1秒內能完成1000筆事務，TPS就是1000了；若是某筆業務響應時間是1s,那麼1個用戶在1秒內只能完成1筆事務，要想達到1000TPS，至少須要1000個用戶；所以能夠說1個用戶能夠產生1000TPS，1000個用戶也能夠產生1000TPS，無非是看響應時間快慢。網絡

Ø 複雜公式： session

試想一下複雜場景，多個腳本，每一個腳本里面定義了多個事務（例如一個腳本里面有100個請求，咱們把這100個連續請求叫作Action,只有第10個請求，第20個請求分別定義了事務10和事務20）具體公式以下：架構

符號表明意義：併發

Vui表示的是第i個腳本使用的併發用戶數數據庫設計

Rtj表示的是第i個腳本第j個事務花費的時間，此時間會影響整個Action時間分佈式

Rti表示的是第i個腳本一次完成全部操做的時間，即Action時間函數

n 表示的是第n個腳本

m 表示的是每一個腳本中m個事務

那麼第j個事務的TPS = Vui/Rti

總的TPS=

4. 如何獲取Vu和TPS

Ø 併發用戶數(Vu)獲取

新系統：沒有歷史數據做參考，只能經過業務部門進行評估。

舊系統：對於已經上線的系統，能夠選取高峯時刻，在必定時間內使用系統的人數，這些人數認爲屬於在線用戶數，併發用戶數取10%就能夠了，例如在半個小時內，使用系統的用戶數爲10000，那麼取10%做爲併發用戶數基本就夠了。

Ø TPS獲取

新系統：沒有歷史數據做參考，只能經過業務部門進行評估。

舊系統：對於已經上線的系統，能夠選取高峯時刻，在5分鐘或10分鐘內，獲取系統每筆交易的業務量和總業務量，按照單位時間內完成的筆數計算出TPS，即業務筆數/單位時間（5*60或10*60）

5. 如何評價系統的性能

針對服務器端的性能，以TPS爲主來衡量系統的性能，併發用戶數爲輔來衡量系統的性能，若是必需要用併發用戶數來衡量的話，須要一個前提，那就是交易在多長時間內完成，由於在系統負載不高的狀況下，將思考時間(思考時間的值等於交易響應時間)加到腳本中，併發用戶數基本能夠增長一倍，所以用併發用戶數來衡量系統的性能沒太大的意義。

6. 相關案例

經過大量性能測試咱們發現不需要用上萬的用戶併發去進行測試，只要系統處理業務時間足夠快，幾百個用戶甚至幾十個用戶就能夠達到目的。另外諮詢不少專家作過的性能測試項目，基本都沒有超過5000用戶併發。

所以對於大型系統、業務量很是高、硬件配置足夠多的狀況下，5000用戶併發就足夠了；對於中小型系統，1000用戶併發就足夠了。

7. 性能測試策略

作性能測試須要一套標準化流程及測試策略，併發用戶數只是指標考慮的一個，在作負載測試的時候，通常都是按照梯度施壓的方式去加用戶數，而不是在沒有預估的狀況下，一次加幾萬個用戶，，交易失敗率很是高，響應時間很是長，已經超過了使用者忍受範圍內，這樣作沒有多大的意義，這就比如「有多少錢能夠幹多少事」同樣，須要選擇相關的策略。

8. Loadrunner VS PTS

從下圖對比項能夠看出，PTS比Loadrunner(LR)更能讓客戶接受。

方向	對比項	Loadrunner	PTS	備註
基礎設施	被測系統軟硬件環境須要額外購買？	須要	不須要	基礎設施軟硬件由阿里雲提供，只須要購買服務
壓力機環境須要額外購買？	須要	不須要	基礎設施軟硬件由PTS提供，只須要購買服務
費用	費用	很是貴	便宜，按需收費	商業化工具License很是貴
功能	功能	強大	較強大	LR不少功能基本上用不到，不必大馬拉小車
易用性	操做、學習等	困難	容易	LR不易上手
穩定性	系統穩定性	較穩定	很是穩定	LR壓測過程當中常常出現莫名其妙錯誤
場景模擬	場景模擬條件	較真實	很是真實	PTS分佈在全國各地的分佈式集羣能夠真實模擬出現實場景，而LR不太容易模擬，即便能夠的話，控制機和壓力機通訊常常掉線

9. 總結

Ø 系統的性能由TPS決定，跟併發用戶數沒有多大關係。在一樣的TPS下，能夠由不一樣的用戶數去壓（經過加思考時間設置）。

原文出處：《併發用戶數與TPS之間的關係》

Ø 系統的最大TPS是必定的（在一個範圍內），但併發用戶數不必定，能夠調整。

Ø 建議性能測試的時候，不要設置過長的思考時間，以最壞的狀況下對服務器施壓。

Ø 通常狀況下，大型系統（業務量大、機器多）作壓力測試，5000個用戶併發就夠了，中小型系統作壓力測試，1000個用戶併發就足夠了

系統吞吐量、TPS（QPS）、用戶併發量、性能測試概念和公式

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，這兩個要素有相對比較穩定的關係（除了放假、季節性因素影響以外）

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工做確定是不飽合的。一方面該服務器可能有多個cpu，可是隻處理單個進程，另外一方面，在處理一個進程中，有些階段多是 IO階段，這個時候會形成CPU等待，可是有沒有其餘請求進程能夠被處理）。隨着併發用戶數的增長，CPU利用率上升，QPS相應也增長（公式爲QPS=併發用戶數/平均響應時間。）隨着併發用戶數的增長，平均響應時間也在增長，並且平均響應時間的增長是一個指數增長曲線。而當併發數增長到很大時，每秒鐘都會有不少請求須要處理，會形成進程（線程）頻繁切換，反正真正用於處理請求的時間變少，每秒可以處理的請求數反而變少，同時用戶的請求等待時間也會變大，甚至超過用戶的心理底線。

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

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

1、軟件性能的關注點

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

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

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

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

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

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

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

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

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

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

一句話，咱們要關注以上全部的性能點。

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

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

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

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

數據庫服務器處理時間：A2