天天看點

不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發

吞吐量

在了解

qps

tps

rt

、并發數之前,首先我們應該明确一個系統的吞吐量到底代表什麼含義,一般來說,系統吞吐量指的是系統的抗壓、負載能力,代表一個系統每秒鐘能承受的最大使用者通路量。

一個系統的吞吐量通常由

qps

(tps)、并發數來決定,每個系統對這兩個值都有一個相對極限值,隻要某一項達到最大值,系統的吞吐量就上不去了。

QPS

Queries Per Second

,每秒查詢數,即是每秒能夠響應的查詢次數,注意這裡的查詢是指使用者送出請求到伺服器做出響應成功的次數,簡單了解可以認為查詢=請求

request

qps

=每秒鐘

request

數量

TPS

Transactions Per Second

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

針對單接口而言,

TPS

可以認為是等價于

QPS

的,比如通路一個頁面

/index.html

,是一個

TPS

,而通路/index.html頁面可能請求了3次伺服器比如

css

js

index

接口,産生了3個

QPS

RT

Response Time

縮寫,簡單了解為系統從輸入到輸出的時間間隔,寬泛的來說,他代表從用戶端發起請求到服務端接受到請求并響應所有資料的時間差。一般取平均響應時間。

并發數

簡而言之,系統能同時處理的請求/事務數量。

計算方式

QPS

= 并發數 /

RT

或者 并發數=

QPS

*

RT

舉個栗子:

假設公司每天早上9點到10點1個小時内都有員工要上廁所,公司有3600個員工,平均每個員工上廁所時間為10分鐘,我們來計算一下。

QPS

   = 3600/(60*60)   1

RT

    = 10*60            600秒

并發數

= 1 * 600          600

這樣就意味着如果想達到最好的蹲坑體驗,公司需要600個坑位來滿足員工需求,否則的話上廁所就要排隊等待了。

性能思考

按照

QPS

=

并發數

/

RT

公式,假設我們現在是單線程的場景,那麼

QPS

公式應該是這樣:

QPS

= 1/RT,實際上

RT

應該=

CPU time

+

CPU wait time

,如果将線程數提高到2,那麼

QPS

= 2/(CPU time + CPU wait time),那麼是否意味着我們隻要單純提高線程數就能提高QPS呢?

最佳線程數計算

假設CPU time是49ms,CPU wait time是200ms,那麼QPS=1000ms/249ms=4.01,這裡200ms的wait時間我們可以認為CPU一直處于等待狀态啥也沒幹,理論上來說200ms還可以接受200/49≈4個請求,不考慮上下文切換和其他開銷的話,可以認為總線程數=(200+49)/49=5,如果再考慮上CPU多核和使用率的問題,我們大緻可以認為:最佳線程數=RT/CPU Time * CPU核心數 * CPU使用率

那麼最大

QPS

公式推導為:

最大

QPS

= 最佳線程數單線程

QPS

=(RT/CPU Time * CPU核心數 * CPU使用率)(1/RT) = CPU核心數*CPU使用率/CPU time

那麼這樣是否意味着我們隻要不停增加CPU核心數就能無限提高QPS呢

阿姆達爾定律Amdahl

不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發

G.M.Amdahl在1967年提出了Amdahl’s law,針對并行處理的scalability給出了一個模型,指出使用并行處理的提速由問題的可并行的部分所決定。我們可以簡單了解為程式通過額外的計算資源,理論上能獲得的加速值。

par為并行計算所占的比例,p為并行處理節點個數

假設你想從望京去順義,坐一輛車需要3小時,雖然現在有3輛車,你也不能1小時就到。這裡無法并行,所有Par=0%,p=3,加速比還是等于1,并沒有提高速度。

古斯塔夫森定律Gustafson

不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發

斯塔夫森定律又被稱為擴充的

加速比

(scaled speedup),他說明處理器個數、串行比例和加速比之間的關系,隻是和阿姆達爾定律側重角度有所不同。

按照阿姆達爾定律和QPS計算公式,在

CPUtime

CPU

使用率不變的情況下,增加

CPU核心數

就能增加最大

QPS

,在

par

不為0即并行的時候,增加并行數量 p 就能提升效率,但是實際上随着請求數量的增加,帶來大量的上下文的切換、gc和鎖變化。qps更高,産生對象越多,

gc

越頻繁,cpu time和使用率都受到影響,尤其在串行的時候,鎖自旋、自适應、偏向等等也成為影響par的因素。

總結

不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發
不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發
不了解 QPS、TPS、RT、并發數、吞吐量,勸你履歷别寫熟悉高并發

繼續閱讀