前言
效能測試指標是評估一個軟體系統是否滿足預期的一個標準。

常用的網站效能測試指標有：QPS、TPS、吞吐量、併發數、響應時間、效能計數器等。

併發數（Concurrent）
併發數（Concurrent）是指系統同時能處理的請求數量，這個也是反應了系統的負載能力。

指同一時間點對業務功能同時操作的使用者數，可以分為兩種：一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事或操作，這時業務功能一般指同一型別的業務；另外一種併發是廣義範圍的併發，這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進行了操作，但是這些請求或都操作可以是相同的，也可以是不同的，這時業務功能可能不是同一型別的業務。

響應時間（Response Time）
響應時間（response time）是一個系統最重要的指標之一，它的數值大小直接反應了系統的快慢。響應時間是指執行一個請求從開始到最後收到響應資料所花費的總體時間。

吞吐量（Throughput）
吞吐量（Throughput）是指單位時間內系統能處理的請求數量，體現系統處理請求的能力，這是目前最常用的效能測試指標。

一段時間內應用系統處理使用者的請求數（以下介紹指單位時間內，也可以理解為吞吐率），這個定義考察點一般是系統本身因素；當然也可以用單位時間內流經被測系統的資料流量，一般單位為b/s,即每秒鐘流經的位元組數，這個定義的考察點既有系統本身因素也有網路，外設等因素，也可以理解為除客戶端以外的測試環境及被測系統。

跟吞吐量有關：併發數、響應時間。

吞吐量的常用量化指標：QPS、TPS、HPS

QPS（每秒查詢數）
QPS：Queries Per Second，意思是每秒查詢率，是一臺伺服器每秒能夠響應的查詢次數（資料庫中的每秒執行查詢sql的次數），不能描述增刪改.

QPS（TPS），併發數、響應時間它們三者之間的關係是：

QPS（TPS）= 併發數 / 平均響應時間

TPS（每秒事務數）
TPS：Transactions Per Second，意思是每秒事務數，具體事務的定義，都是人為的，可以一個介面、多個介面、一個業務流程等等。一個事務是指事務內第一個請求傳送到接收到最後一個請求的響應的過程，以此來計算使用的時間和完成的事務個數。

HPS（每秒HTTP請求數）
HPS：Hits per Second 每秒點選次數，是指在一秒鐘的時間內使用者對Web頁面的連結、提交按鈕等點選總和。 它一般和TPS成正比關係，是B/S系統中非常重要的效能指標之一。

TPS
TPS定義
TPS是Transaction per Second的縮寫，也就是事物數/秒。它是軟體測試結果的測量單位，一個事物是指一個客戶機向伺服器傳送請求飯後伺服器做出反應的過程。
　　客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用時間和完成的事物數，最終利用這些資訊來估計得分。

以單介面定義為事務為例，每個事務包括瞭如下3個過程：

　　a.向伺服器發請求

　　b.伺服器自己的內部處理（包含應用伺服器、資料庫伺服器等）

　　c.伺服器返回結果給客戶端

　　如果每秒能夠完成N次這三個過程，tps就是N；

如果多個介面定義為一個事務，那麼，會重複執行abc，完成一次這幾個請求，算做一個tps。

TPS 效能測試中的作用
反映了系統在同一時間內處理業務的最大能力，這個資料越高，說明處理能力越強，描述（看到系統的TPS隨著時間的變化逐漸變大，而在不到多少分鐘的時候系統
　　每秒可以處理多少個事物。這裡的最高值並不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨著負載增加而逐漸增加，當系統進入繁忙期後，TPS會有所下降。）而在幾分鐘以後開始出現少量的失敗事物）

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

2、系統吞吐量幾個重要引數：TPS、併發數、響應時間（TPS = 併發數 / 平均響應時間）

3、利用TPS計算系統最高日吞吐量；

4、找出系統最高TPS和日PV，這兩個要素有相對比較穩定的關係。

5、通過壓力測試或者經營評估，得出最高TPS，然後跟進的關係，計算出系統最高日吞吐量。例如：B2B中文和淘寶對客戶群不一樣，這兩個客戶群的網路行為不應用，他們之間的TPS和PV關係比例也不一樣。

TPS與響應時間的關係
1、TPS和響應時間在理想狀態下的額定值。如果20個入口，併發數只有10的時候，TPS就是10，而響應時間始終都是1，說明併發不夠，需要增加併發數達到TPS的峰值。

2、如果增加到100併發，則造成了執行緒等待，引起平均響應時間從 1 秒變成 3 秒，TPS也從20下降到9；TPS和響應時間都是單獨計算出來的，兩者不是互相計算出來的。

3、響應時間和TPS在巨集觀上是反比的關係，但是兩者之間沒有直接關係。

TPS 總結
1、利用併發使用者數、期望響應時間，可以計算出TPS。

2、TPS只是用來計算的是期望值，效能測試過程中的TPS無法單獨作為效能指標。

3、TPS資料方位理論值贏在10-100之間，低於10和高於100都說明系統存在瓶頸點。

4、利用TPS與平均事物響應時間進行對比，可以分析事物數碼對執行時間的影響。例：當壓力加大，點選率/tps曲線如果變化緩慢或者有平坦趨勢，很有可能是伺服器開始出現瓶頸。

5、TPS是從客戶端角度審視伺服器處理能力，不能證明TPS可以達到什麼程度就能支援多少併發，兩者沒有必然聯絡。

6、TPS會受到負載的影響，也會隨著負載的增加而逐漸增加，當系統進入繁忙期後，TPS會有所下降。

Jmeter聚合報告 Throughput
Throughput：分為網路吞吐量和事務吞吐量，當作為事務吞吐量時，採用TPS來衡量。

Jmeter聚合報告中，Throughput是用來衡量請求的吞吐量，也就是TPS，TPS=樣本數/執行時間；我們定義的是TPS，不是QPS，如果沒有定義事務，會把每個請求作為一個事務。

CPU的利用率、吞吐量、響應時間 三者關係

————————————————
版權宣告：本文為CSDN博主「BenjaminQA」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/qq_25305833/article/details/122018709