吞吐量

在了解qps、tps、rt、并發(fā)數(shù)之前，首先我們應(yīng)該明確一個(gè)系統(tǒng)的吞吐量到底代表什么含義，一般來說，系統(tǒng)吞吐量指的是系統(tǒng)的抗壓、負(fù)載能力，代表一個(gè)系統(tǒng)每秒鐘能承受的最大用戶訪問量。

一個(gè)系統(tǒng)的吞吐量通常由qps（tps）、并發(fā)數(shù)來決定，每個(gè)系統(tǒng)對(duì)這兩個(gè)值都有一個(gè)相對(duì)極限值，只要某一項(xiàng)達(dá)到最大值，系統(tǒng)的吞吐量就上不去了。

QPS

Queries Per Second，每秒查詢數(shù)，即是每秒能夠響應(yīng)的查詢次數(shù)，注意這里的查詢是指用戶發(fā)出請(qǐng)求到服務(wù)器做出響應(yīng)成功的次數(shù)，簡單理解可以認(rèn)為查詢=請(qǐng)求request。

qps=每秒鐘request數(shù)量

TPS

Transactions Per Second 的縮寫，每秒處理的事務(wù)數(shù)。一個(gè)事務(wù)是指一個(gè)客戶機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過程。客戶機(jī)在發(fā)送請(qǐng)求時(shí)開始計(jì)時(shí)，收到服務(wù)器響應(yīng)后結(jié)束計(jì)時(shí)，以此來計(jì)算使用的時(shí)間和完成的事務(wù)個(gè)數(shù)。

針對(duì)單接口而言，TPS可以認(rèn)為是等價(jià)于QPS的，比如訪問一個(gè)頁面/index.html，是一個(gè)TPS，而訪問/index.html頁面可能請(qǐng)求了3次服務(wù)器比如css、js、index接口，產(chǎn)生了3個(gè)QPS。

tps=每秒鐘事務(wù)數(shù)量

RT

Response Time縮寫，簡單理解為系統(tǒng)從輸入到輸出的時(shí)間間隔，寬泛的來說，他代表從客戶端發(fā)起請(qǐng)求到服務(wù)端接受到請(qǐng)求并響應(yīng)所有數(shù)據(jù)的時(shí)間差。一般取平均響應(yīng)時(shí)間。

并發(fā)數(shù)

簡而言之，系統(tǒng)能同時(shí)處理的請(qǐng)求/事務(wù)數(shù)量。

計(jì)算方式

QPS=并發(fā)數(shù)/RT 或者 并發(fā)數(shù)=QPS*RT

舉個(gè)栗子：

假設(shè)公司每天早上9點(diǎn)到10點(diǎn)1個(gè)小時(shí)內(nèi)都有員工要上廁所，公司有3600個(gè)員工，平均每個(gè)員工上廁所時(shí)間為10分鐘，我們來計(jì)算一下。

QPS    = 3600/(60*60)   1

RT      = 10*60            600秒

并發(fā)數(shù) = 1 * 600          600

這樣就意味著如果想達(dá)到最好的蹲坑體驗(yàn)，公司需要600個(gè)坑位來滿足員工需求，否則的話上廁所就要排隊(duì)等待了。

性能思考

按照QPS=并發(fā)數(shù)/RT公式，假設(shè)我們現(xiàn)在是單線程的場景，那么QPS公式應(yīng)該是這樣：QPS=1/RT，實(shí)際上RT應(yīng)該=CPU time + CPU wait time，如果將線程數(shù)提高到2，那么QPS=2/(CPU time + CPU wait time)，那么是否意味著我們只要單純提高線程數(shù)就能提高QPS呢？

最佳線程數(shù)計(jì)算

假設(shè)CPU time是49ms，CPU wait time是200ms，那么QPS=1000ms/249ms=4.01，這里200ms的wait時(shí)間我們可以認(rèn)為CPU一直處于等待狀態(tài)啥也沒干，理論上來說200ms還可以接受200/49≈4個(gè)請(qǐng)求，不考慮上下文切換和其他開銷的話，可以認(rèn)為總線程數(shù)=(200+49)/49=5，如果再考慮上CPU多核和利用率的問題，我們大致可以認(rèn)為：最佳線程數(shù)=RT/CPU Time * CPU核心數(shù) * CPU利用率

那么最大QPS公式推導(dǎo)為：

最大QPS=最佳線程數(shù)*單線程QPS=（RT/CPU Time * CPU核心數(shù) * CPU利用率）*（1/RT) = CPU核心數(shù)*CPU利用率/CPU time

那么這樣是否意味著我們只要不停增加CPU核心數(shù)就能無限提高QPS呢

阿姆達(dá)爾定律Amdahl

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

par為并行計(jì)算所占的比例，p為并行處理節(jié)點(diǎn)個(gè)數(shù)

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

古斯塔夫森定律Gustafson

斯塔夫森定律又被稱為擴(kuò)展的加速比(scaled speedup)，他說明處理器個(gè)數(shù)、串行比例和加速比之間的關(guān)系，只是和阿姆達(dá)爾定律側(cè)重角度有所不同。

按照阿姆達(dá)爾定律和QPS計(jì)算公式，在CPUtime 和 CPU利用率不變的情況下，增加CPU核心數(shù)就能增加最大QPS，在par不為0即并行的時(shí)候，增加并行數(shù)量p就能提升效率，但是實(shí)際上隨著請(qǐng)求數(shù)量的增加，帶來大量的上下文的切換、gc和鎖變化。qps更高，產(chǎn)生對(duì)象越多，gc越頻繁，cpu time和利用率都受到影響，尤其在串行的時(shí)候，鎖自旋、自適應(yīng)、偏向等等也成為影響par的因素。

總結(jié)，為了提升達(dá)到最好的性能，我們需要不斷的進(jìn)行性能測(cè)試，調(diào)整小城池大小，找到最合適的參數(shù)來達(dá)到提高性能的目的。

參考：

http://javahao123.com/?p=772

https://cloud.tencent.com/developer/article/1106559

https://www.cnblogs.com/caishunzhe/p/13056105.html

https://www.jianshu.com/p/8532ac88ce72

https://zhuanlan.zhihu.com/p/66929848

https://www.cnblogs.com/lupeng2010/p/12705795.html

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
			

		

		

			
		

長按訂閱更多精彩▼
		

			
如有收獲，點(diǎn)個(gè)在看，誠摯感謝