（轉）性能測試基本指標

時間 2019-12-09

標籤性能測試基本指標欄目系統性能简体版

原文原文鏈接

轉自：http://www.javashuo.com/article/p-pojecqdp-gx.htmlhtml

一．系統吞度量要素：數據庫

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

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

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

併發數：系統同時處理的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