硬核乾貨！QPS、TPS、併發用戶數、吞吐量關係

一、QPS

---

QPS Queries Per Second  是每秒查詢率 ,是一臺服務器每秒可以相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準, 即每秒的響應請求數，也便是最大吞吐能力。

二、TPS

---

TPS Transactions Per Second也就是事務數/秒。一個事務是指一個客戶機向服務器發送請求而後服務器作出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數，

三、QPS和TPS區別

---

我的理解以下：

一、Tps即每秒處理事務數，包括了

• 用戶請求服務器  
• 服務器本身的內部處理  
• 服務器返回給用戶

這三個過程，每秒可以完成N個這三個過程，Tps也就是N；

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

例子：

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

例如：一個大胃王一秒能吃10個包子，一個女孩子0.1秒能吃1個包子，那麼他們是否是同樣的呢？答案是否認的，由於這個女孩子不可能在一秒鐘吃下10個包子，她可能要吃好久。這個時候這個大胃王就至關於TPS，而這個女孩子則是QPS。雖然很類似，但實際上是不一樣的。

四、併發數

---

併發數（併發度）：指系統同時能處理的請求數量，一樣反應了系統的負載能力。這個數值能夠分析機器1s內的訪問日誌數量來獲得

五、吐吞量

---

吞吐量是指系統在單位時間內處理請求的數量，TPS、QPS都是吞吐量的經常使用量化指標。

系統吞吐量要素

一個系統的吞吐量（承壓能力）與request（請求）對cpu的消耗，外部接口，IO等等緊密關聯。

單個request 對cpu消耗越高，外部系統接口，IO影響速度越慢，系統吞吐能力越低，反之越高。

重要參數

QPS(TPS),併發數，響應時間

• QPS(TPS)：每秒鐘request/事務 數量
• 併發數：系統同時處理的request/事務數
• 響應時間：通常取平均響應時間

關係

QPS(TPS)=併發數/平均響應時間

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

六、PV

---

PV（Page View）：頁面訪問量，即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次。能夠統計服務一天的訪問日誌獲得。 

七、UV 

---

UV（Unique Visitor）：獨立訪客，統計1天內訪問某站點的用戶數。能夠統計服務一天的訪問日誌並根據用戶的惟一標識去重獲得。響應時間（RT）：響應時間是指系統對請求做出響應的時間，通常取平均響應時間。能夠經過Nginx、Apache之類的Web Server獲得。 

八、DAU

---

DAU(Daily Active User)，日活躍用戶數量。經常使用於反映網站、互聯網應用或網絡遊戲的運營狀況。DAU一般統計一日（統計日）以內，登陸或使用了某個產品的用戶數（去除重複登陸的用戶），與UV概念類似 

九、MAU

---

MAU(Month Active User)：月活躍用戶數量，指網站、app等去重後的月活躍用戶數量

十、系統吞吐量評估

---

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

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

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

一般的技術方法：

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

二、經過壓力測試或者經驗預估，得出最高TPS，而後跟進1的關係，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶羣不同，這兩個客戶羣的網絡行爲不該用，他們之間的TPS和PV關係比例也不同。

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

---

軟件作性能測試時須要關注哪些性能呢？

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

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

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

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

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

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

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

來源： 
https://juejin.im/post/5c2cb5...

最新整理的 2TB 技術乾貨：包括架構師實戰教程、大數據、Docker容器、系統運維、數據庫、redis、MogoDB、電子書、Java基礎課程、Java實戰項目、ELK Stack、機器學習、BAT面試精講視頻等。只需在「 民工哥技術之路」微信公衆號對話框回覆關鍵字：1024便可獲取所有資料。