秒懂QPS、TPS、PV、UV、GMV、IP、RPS

藍隊云小課堂：

QPS

Queries Per Second，每秒查詢數。每秒能夠響應的查詢次數。

QPS 是一臺服務器每秒能夠相應的查詢次數，即1秒內完成的請求數量，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準

QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。每秒的響應請求數，也即是最大吞吐能力。

TPS

Transactions Per Second 的縮寫，每秒處理的事務數目。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些信息作出的評估分。

TPS 的過程包括：客戶端請求服務端、服務端內部處理、服務端返回客戶端。

例如，訪問一個 Index 頁面會請求服務器 3 次，包括一次 html，一次 css，一次 js，那么訪問這一個頁面就會產生一個“T”，產生三個“Q”。

QPS 與 TPS 區別

QPS基本類似于TPS，但是不同的是，對于一個Web頁面的一次訪問，形成一個TPS（就做一件事兒，打開Web網頁）；但一次Web頁面請求，可能產生多次對服務器的請求（html、css、js、images、files等），服務器對這些請求，就可計入QPS之中。每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。

一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。

如果是對一個接口（單場景）壓測，且這個接口內部不會再去請求其它接口，那么TPS等于QPS，否則，若這個接口內部還會再去請求其它接口（下載圖片、文件等服務器接口），那么 TPS不等于QPS，通常是 QPS會大于TPS

PV

page view即頁面瀏覽量

通常是衡量一個網絡新聞頻道或網站甚至一條網絡新聞的主要指標。

用戶每一次對網站中的每個頁面訪問均被記錄 1 次。

用戶對同一頁面的多次刷新，訪問量累計。

根據這個特性，刷網站的 PV 就很好刷了。

與 PV 相關的還有 RV，即重復訪問者數量（repeat visitors）。

UV

Unique Visitor 指獨立訪客訪問數，統計1天內訪問某站點的用戶數(以 cookie 為依據)，一臺電腦終端為一個訪客。

IP

Internet Protocol獨立 IP 數

是指 1 天內多少個獨立的 IP 瀏覽了頁面，即統計不同的 IP 瀏覽用戶數量。

同一 IP 不管訪問了幾個頁面，獨立 IP 數均為 1；

不同的 IP 瀏覽頁面，計數會加 1。

IP 是基于用戶廣域網 IP 地址來區分不同的訪問者的，所以，多個用戶（多個局域網 IP）在同一個路由器（同一個廣域網 IP）內上網，可能被記錄為一個獨立 IP 訪問者。如果用戶不斷更換 IP，則有可能被多次統計。

RT

Response Time 響應時間是一個系統最重要的指標之一，它的數值大小直接反應了系統的快慢。

響應時間是指系統對請求作出響應的時間。直觀上看，這個指標與人對軟件性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。由于一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。當然，往往也需要對每個或每組功能討論其平均響應時間和最大響應時間。

對于單機的沒有并發操作的應用系統而言，人們普遍認為響應時間是一個合理且準確的性能指標。需要指出的是，響應時間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實際上取決于用戶對該響應時間的接受程度。對于一個游戲軟件來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對于編譯系統來說，完整編譯一個較大規模軟件的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于用戶來說都是可以接受的。

響應時間是指執行一個請求從開始到最后收到響應數據所花費的總體時間,即從客戶端發起請求到收到服務器響應結果的時間

GMV

Gross Merchandise Volume 的簡稱。只要是訂單，不管消費者是否付款、賣家是否發貨、是否退貨，都可放進 GMV 。

RPS

RPS 代表吞吐率，即 Requests Per Second 的縮寫。吞吐率是服務器并發處理能力的量化描述，單位是 reqs/s，指的是某個并發用戶數下單位時間內處理的請求數。

某個并發用戶數下單位時間內能處理的最大的請求數，稱之為最大吞吐率。

有人把 RPS 說等效于 QPS。其實可以看作同一個統計方式，只是叫法不同而已。RPS/QPS，可以使用 apche ab 工具進行測量。

QPS、PV 、RT 之間的關系

在進行系統性能壓測和系統性能優化的時候，會涉及到QPS,PV,RT相關的概念， QPS,PV,RT之間的關系

• 對于大部分web系統，響應時間一般由CPU執行時間，線程等待時間（IO等待，sleep, wait）時間組成，QPS和RT成反比關系

• 在實際的測試環境中，QPS和RT并不是非常直接的反比關系

QPS 是什么

QPS：單個進程每秒請求服務器的成功次數 QPS = req/sec = 請求數/秒

QPS如何統計

QPS統計方式 [一般使用 http_load 進行統計] QPS = 總請求數 / ( 進程總數 * 請求時間 )

根據QPS推算PV：

單臺服務器每天PV計算:

公式1：每天總PV = QPS * 3600 * 6 公式2：每天總PV = QPS * 3600 * 8

根據QPS，PV推算服務器數量

服務器數量 = 每天總PV / 單臺服務器每天總PV

峰值QPS和機器計算公式：

原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間

峰值時間每秒請求數(QPS)：( 總PV數 * 80% ) / ( 每天秒數 * 20% )

峰值機器數量：峰值時間QPS / 單臺機器的QPS

例子：

問：每天300w PV 的在單臺機器上，這臺機器需要多少QPS？

答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問：如果一臺機器的QPS是58，需要幾臺機器來支持？

答：139 / 58 = 3

• 對于大部分web系統，響應時間一般由CPU執行時間，線程等待時間（IO等待，sleep, wait）時間組成，QPS和RT成反比關系

• 在實際的測試環境中，QPS和RT并不是非常直接的反比關系

最佳線程數

性能壓測的情況下，起初隨著用戶數的增加，QPS會上升，當到了一定的閥值之后，用戶數量增加QPS并不會增加，或者增加不明顯，同時請求的響應時間卻大幅增加，這個閥值我們認為是最佳線程數。

剛好消耗完服務器的瓶頸資源的臨界線程數，公式如下

最佳線程數量 =（（線程等待時間 + 線程CPU執行時間）/ 線程CPU執行時間）* CPU數量

特性：

• 在達到最佳線程數的時候，線程數量繼續遞增，則QPS不變，而響應時間變長，持續遞增線程數量，則QPS開始下降

• 每個系統都有其最佳線程數量，但是不同狀態下，最佳線程數量是會變化的

• 瓶頸資源可以是CPU,可以是內存，可以是鎖資源，IO資源

超過最佳線程數，會導致資源的競爭；超過最佳線程數，會響應時間遞增。

為什么要找最佳線程數

• 過多的線程只會造成，更多的內存開銷，更多的CPU開銷，但是對提升QPS確毫無幫助

• 找到最佳線程數后通過簡單的設置，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出

最佳線程數的獲取：

• 通過用戶慢慢遞增來進行性能壓測，觀察QPS，響應時間

• 根據公式計算:服務器端最佳線程數量=((線程等待時間+線程cpu時間)/線程cpu時間) *      cpu數量

• 單用戶壓測，查看CPU的消耗，然后直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳線程數量。      

影響最佳線程數的主要因素

• IO

IO開銷較多的應用其CPU線程等待時間會比較長，所以線程數量可以開的多一些，相反則線程數量要少一些，其實有兩種極端，純IO的應用，比如proxy，則線程數量可以開到非常大（實在太大了則需要考慮線程切換的開銷），這種應用基本上后端（比如這個proxy是代理搜索的）的QPS能有多少，proxy就有多少。

• CPU

對于耗CPU的計算，這種情況一般來講只能開到CPU個數的線程數量。但是并不是說這種應用的QPS就不高，往往這種應用的QPS可以很高，因為耗CPU計算的應用，往往處理單次請求的時間會很短。

QPS和線程數的關系

在最佳線程數量之前，QPS和線程是互相遞增的關系，線程數量到了最佳線程之后，QPS持平，不在上升，甚至略有下降，同時響應時間持續上升。

同一個系統而言，最佳線程數越多，QPS越高

并發數**（**Parallels）

并發數是指系統同時能處理的請求數量，一般跟CPU個數，線程數有關，這反應了系統的負載能力

并發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量。與吞吐量相比，并發用戶數是一個更直觀但也更籠統的性能指標。實際上，并發用戶數是一個非常不準確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。一網站系統為例，假設用戶只有注冊后才能使用，但注冊用戶并不是每時每刻都在使用該網站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網站時會花很多時間閱讀網站上的信息，因而具體一個時刻只有部分在線用戶同時向系統發出請求。這樣，對于網站系統我們會有三個關于用戶數的統計數字：注冊用戶數、在線用戶數和同時發請求用戶數。由于注冊用戶可能長時間不登陸網站，使用注冊用戶數作為性能指標會造成很大的誤差。而在線用戶數和同事發請求用戶數都可以作為性能指標。相比而言，以在線用戶作為性能指標更直觀些，而以同時發請求用戶數作為性能指標更準確些。

吞吐量**（**Throughput）

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

吞吐量是指系統在單位時間內處理請求的數量。對于無并發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。前面已經說過，對于單用戶的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對于并發系統，通常需要用吞吐量作為性能指標。

對于一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由于每個請求的處理過程中有許多不走難以并發執行，這導致在具體的一個時間點，所占資源往往并不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間并不隨用戶數的增加而線性增加。實際上，不同系統的平均響應時間隨用戶數增加而增長的速度也不大相同，這也是采用吞吐量來度量并發系統的性能的主要原因。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。

并發量、QPS、RT 之間的關系：

QPS = 并發量 / 平均響應時間 （推薦）

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

假設每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間

公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)

機器：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器

每天300w PV 的在單臺機器上，這臺機器需要多少QPS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

如果一臺機器的QPS是58，需要幾臺機器來支持？

139 / 58 = 3 （進一法，取上限）

單線程QPS公式，QPS=1000ms/RT,對同一個系統而言，支持的線程數越多，QPS越高。

假設一個RT是80ms,則可以很容易的計算出QPS,QPS = 1000/80 = 12.5

多線程場景，如果把服務端的線程數提升到2，那么整個系統的QPS則為 2*（1000/80） = 25,

可見QPS隨著線程的增加而線性增長，那QPS上不去就加線程唄，聽起來很有道理，公司也說的通，但是往往現實并非如此。

如何提升RT（響應時間）

• 減少 IO 的響應時間，減少 IO 的調用次數

并發HTTP請求，無上下文依賴，多個連接，一個線程

HTTP連接池（長連接，keep-alive）

• 減少 CPU 的使用時間

forest 循環的例子

如何提升 QPS（每秒查詢數）

• 減少 CPU 的使用時間

• 增加 CPU 的數量

• 減少同步鎖

如果 CPU 不能被壓到 85% 以上，并且此時的OPS已經達到了峰值，則說明另有瓶頸，接下去要重點關注內存

排查內存是否有瓶頸

判斷依據，是在最佳線程數量 * 5 左右的情況下，進行壓測，觀察 Old 區內存增長是否正常

性能壓測要關注使用了多少用戶數，目前的壓測方式容易遺漏內存瓶頸

總結

• Proxy 應用（耗IO）的線程越多越好，當線程達到過多時，線程本身資源的開銷也會成為瓶頸，線程本身也是一個資源。

所以這類Proxy應用一般采取輕程模型，NIO解決，如 nginx

• 計算型應用（耗CPU），線程數量就是CPU的核數，如搜索索引服務器，需要做大量的計算排序，非常耗CPU資源

更多小知識，可聯系藍隊云一起探討。