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

藍隊云小課堂：

QPS

Queries Per Second，每秒查詢數(shù)。每秒能夠響應(yīng)的查詢次數(shù)。

QPS 是一臺服務(wù)器每秒能夠相應(yīng)的查詢次數(shù)，即1秒內(nèi)完成的請求數(shù)量，是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標準

QPS是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標準，在因特網(wǎng)上，作為域名系統(tǒng)服務(wù)器的機器的性能經(jīng)常用每秒查詢率來衡量。每秒的響應(yīng)請求數(shù)，也即是最大吞吐能力。

TPS

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

TPS 的過程包括：客戶端請求服務(wù)端、服務(wù)端內(nèi)部處理、服務(wù)端返回客戶端。

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

QPS 與 TPS 區(qū)別

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

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

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

PV

page view即頁面瀏覽量

通常是衡量一個網(wǎng)絡(luò)新聞頻道或網(wǎng)站甚至一條網(wǎng)絡(luò)新聞的主要指標。

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

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

根據(jù)這個特性，刷網(wǎng)站的 PV 就很好刷了。

與 PV 相關(guān)的還有 RV，即重復(fù)訪問者數(shù)量（repeat visitors）。

UV

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

IP

Internet Protocol獨立 IP 數(shù)

是指 1 天內(nèi)多少個獨立的 IP 瀏覽了頁面，即統(tǒng)計不同的 IP 瀏覽用戶數(shù)量。

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

不同的 IP 瀏覽頁面，計數(shù)會加 1。

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

RT

Response Time 響應(yīng)時間是一個系統(tǒng)最重要的指標之一，它的數(shù)值大小直接反應(yīng)了系統(tǒng)的快慢。

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

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

響應(yīng)時間是指執(zhí)行一個請求從開始到最后收到響應(yīng)數(shù)據(jù)所花費的總體時間,即從客戶端發(fā)起請求到收到服務(wù)器響應(yīng)結(jié)果的時間

GMV

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

RPS

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

某個并發(fā)用戶數(shù)下單位時間內(nèi)能處理的最大的請求數(shù)，稱之為最大吞吐率。

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

QPS、PV 、RT 之間的關(guān)系

在進行系統(tǒng)性能壓測和系統(tǒng)性能優(yōu)化的時候，會涉及到QPS,PV,RT相關(guān)的概念， QPS,PV,RT之間的關(guān)系

• 對于大部分web系統(tǒng)，響應(yīng)時間一般由CPU執(zhí)行時間，線程等待時間（IO等待，sleep, wait）時間組成，QPS和RT成反比關(guān)系

• 在實際的測試環(huán)境中，QPS和RT并不是非常直接的反比關(guān)系

QPS 是什么

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

QPS如何統(tǒng)計

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

根據(jù)QPS推算PV：

單臺服務(wù)器每天PV計算:

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

根據(jù)QPS，PV推算服務(wù)器數(shù)量

服務(wù)器數(shù)量 = 每天總PV / 單臺服務(wù)器每天總PV

峰值QPS和機器計算公式：

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

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

峰值機器數(shù)量：峰值時間QPS / 單臺機器的QPS

例子：

問：每天300w PV 的在單臺機器上，這臺機器需要多少Q(mào)PS？

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

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

答：139 / 58 = 3

• 對于大部分web系統(tǒng)，響應(yīng)時間一般由CPU執(zhí)行時間，線程等待時間（IO等待，sleep, wait）時間組成，QPS和RT成反比關(guān)系

• 在實際的測試環(huán)境中，QPS和RT并不是非常直接的反比關(guān)系

最佳線程數(shù)

性能壓測的情況下，起初隨著用戶數(shù)的增加，QPS會上升，當(dāng)?shù)搅艘欢ǖ拈y值之后，用戶數(shù)量增加QPS并不會增加，或者增加不明顯，同時請求的響應(yīng)時間卻大幅增加，這個閥值我們認為是最佳線程數(shù)。

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

最佳線程數(shù)量 =（（線程等待時間 + 線程CPU執(zhí)行時間）/ 線程CPU執(zhí)行時間）* CPU數(shù)量

特性：

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

• 每個系統(tǒng)都有其最佳線程數(shù)量，但是不同狀態(tài)下，最佳線程數(shù)量是會變化的

• 瓶頸資源可以是CPU,可以是內(nèi)存，可以是鎖資源，IO資源

超過最佳線程數(shù)，會導(dǎo)致資源的競爭；超過最佳線程數(shù)，會響應(yīng)時間遞增。

為什么要找最佳線程數(shù)

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

• 找到最佳線程數(shù)后通過簡單的設(shè)置，可以讓web系統(tǒng)更加穩(wěn)定，得到最高，最穩(wěn)定的QPS輸出

最佳線程數(shù)的獲?。?/span>

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

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

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

影響最佳線程數(shù)的主要因素

• IO

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

• CPU

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

QPS和線程數(shù)的關(guān)系

在最佳線程數(shù)量之前，QPS和線程是互相遞增的關(guān)系，線程數(shù)量到了最佳線程之后，QPS持平，不在上升，甚至略有下降，同時響應(yīng)時間持續(xù)上升。

同一個系統(tǒng)而言，最佳線程數(shù)越多，QPS越高

并發(fā)數(shù)**（**Parallels）

并發(fā)數(shù)是指系統(tǒng)同時能處理的請求數(shù)量，一般跟CPU個數(shù)，線程數(shù)有關(guān)，這反應(yīng)了系統(tǒng)的負載能力

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

吞吐量**（**Throughput）

吞吐量是指單位時間內(nèi)系統(tǒng)能處理的請求數(shù)量，體現(xiàn)系統(tǒng)處理請求的能力，這是目前最常用的性能測試指標

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

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

并發(fā)量、QPS、RT 之間的關(guān)系：

QPS = 并發(fā)量 / 平均響應(yīng)時間 （推薦）

并發(fā)量 = QPS * 平均響應(yīng)時間

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

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

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

每天300w PV 的在單臺機器上，這臺機器需要多少Q(mào)PS？

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

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

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

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

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

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

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

如何提升RT（響應(yīng)時間）

• 減少 IO 的響應(yīng)時間，減少 IO 的調(diào)用次數(shù)

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

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

• 減少 CPU 的使用時間

forest 循環(huán)的例子

如何提升 QPS（每秒查詢數(shù)）

• 減少 CPU 的使用時間

• 增加 CPU 的數(shù)量

• 減少同步鎖

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

排查內(nèi)存是否有瓶頸

判斷依據(jù)，是在最佳線程數(shù)量 * 5 左右的情況下，進行壓測，觀察 Old 區(qū)內(nèi)存增長是否正常

性能壓測要關(guān)注使用了多少用戶數(shù)，目前的壓測方式容易遺漏內(nèi)存瓶頸

總結(jié)

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

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

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

更多小知識，可聯(lián)系藍隊云一起探討。