轉(zhuǎn)：http://www.10tiao.com/html/439/201512/423511225/1.html
性能分析的基本概念：QPS/TPS
很多人不會(huì)做性能分析或者調(diào)優(yōu)的關(guān)鍵點(diǎn)在于：不知道怎么做性能分析锭吨。很多人覺得性能調(diào)優(yōu)是一件很難的事情孩饼，無(wú)從下手魁亦。其實(shí)這些都有方法谤逼，只要掌握了一定的方法和技巧叠赐，這不是一件很復(fù)雜的事情。
兩個(gè)最樸實(shí)的概念:QPS/TPS
QPS:Query Per Second
TPS:Transactions Per Second
這兩個(gè)概念起源于數(shù)據(jù)庫(kù)系統(tǒng)，是衡量數(shù)據(jù)庫(kù)性能的重要指標(biāo)。
數(shù)據(jù)庫(kù)的操作可以分為增损话、刪、改槽唾、查這幾類丧枪。
QPS用在對(duì)于查詢類的性能統(tǒng)計(jì)，這類查詢基本不需要在事務(wù)塊中進(jìn)行限制庞萍，不用在獨(dú)立的事務(wù)塊中保持獨(dú)立拧烦；對(duì)于非查詢類，通常是需要在事務(wù)塊中進(jìn)行數(shù)據(jù)的ACID保證钝计，所以對(duì)事務(wù)或者資源具有獨(dú)占性恋博，性能情況會(huì)受制于獨(dú)占資源的消耗齐佳。`
在應(yīng)用系統(tǒng)中，QPS和TPS的概念經(jīng)常已經(jīng)混淆债沮。
但是其基本語(yǔ)義未變：可以泛指在特定周期內(nèi)的處理能力重虑。
影響QPS/TPS的主要因數(shù)
先舉例幾個(gè)壓測(cè)是經(jīng)常遇到的幾個(gè)場(chǎng)景
場(chǎng)景1：**線程池和QPS的關(guān)系**
某一天一個(gè)開發(fā)做壓力測(cè)試。在一臺(tái)4核機(jī)器上測(cè)試秦士。先是用10個(gè)用戶壓測(cè),測(cè)出QPS為60;
再用20個(gè)用戶壓測(cè),測(cè)試QPS 為100;
最后一次用30個(gè)用戶壓測(cè),測(cè)試QPS為100,怎么30個(gè)用戶的QPS 就不增加了呢?
于是他增加了線程池的線程數(shù)量由10調(diào)整到30,再次使用30個(gè)用戶進(jìn)行壓測(cè),居然QPS還是200左右。
他索性又把線程池的線程數(shù)量增加到50,再次30個(gè)用戶壓測(cè),奇怪了!怎么QPS還是200左右,沒有增加呢!
請(qǐng)問:為什么增加線程池,QPS先是上升,再次增加就不上升了呢?
場(chǎng)景2：**什么是瓶頸資源**
某一天這個(gè)開發(fā)做壓?測(cè)試永高。在一臺(tái)4核機(jī)器上測(cè)試隧土。??
這次是一個(gè)新的業(yè)務(wù),此業(yè)務(wù)中含有數(shù)據(jù)庫(kù)事務(wù),對(duì)單條記錄操作的時(shí)候會(huì)上鎖。
于是他開始測(cè)試,用10個(gè)用戶壓測(cè),測(cè)試QPS為40左右;
于是他用20個(gè)用戶壓測(cè),居然還是40左右;30個(gè)用戶,依然如此命爬。
好吧,既然不想,老招數(shù),加?大線程池,由10上升到20,再到30依然沒有曹傀。
絕望了,性能實(shí)驗(yàn)室,有臺(tái)8核機(jī)器,來(lái)吧,試試。饲宛。皆愉。。 QPS居然還是40左右艇抠。幕庐。。
請(qǐng)問:為什么增加線程池,甚?至增加CPU核數(shù),QPS沒有增加呢?
場(chǎng)景3：**響應(yīng)時(shí)間和QPS的關(guān)系**
某?天這個(gè)開發(fā)接到一個(gè)任務(wù)家淤。又是煩人的外圍配合改造,改造是這樣的:某個(gè)系統(tǒng)做了性能優(yōu)化,老的服務(wù)調(diào)用需要50ms,?現(xiàn)在只需要20ms异剥。
這個(gè)開發(fā)一想,這不是很好嘛,可以減少業(yè)務(wù)處理時(shí)間,那請(qǐng)求的響應(yīng)時(shí)間自然就變少了,那QPS不是就增加了么?
想的倒是很美。絮重。冤寿。于是配合改造,發(fā)布上線,到線上一看,XX的,響應(yīng)時(shí)間確實(shí)少了,但是怎么QPS沒有增加呢?
請(qǐng)問:為什么響應(yīng)時(shí)間變少,QPS沒有增加,響應(yīng)時(shí)間和QPS的關(guān)系是什么呢?
通過(guò)上面的幾個(gè)場(chǎng)景，沒有經(jīng)驗(yàn)的人可能會(huì)比較迷惑青伤。
傳統(tǒng)QPS公式可以寫成：QPS = 1000ms/響應(yīng)時(shí)間 * CPU核數(shù)督怜，這個(gè)是多數(shù)人的理解：
當(dāng)機(jī)器由4核換成8核的時(shí)候，QPS一定是會(huì)增加的狠角，因?yàn)榭梢杂糜谔幚淼腃PU更多了
當(dāng)響應(yīng)時(shí)間變少的時(shí)候号杠，分母變小了，所以QPS增加了丰歌。
但是通過(guò)上面的例子可以看出究流，實(shí)驗(yàn)結(jié)果不是想得這樣。（當(dāng)然如果你懷疑列舉的場(chǎng)景动遭，可以自己做下實(shí)驗(yàn)）
那么問題來(lái)了：**是什么影響了QPS芬探，QPS和CPU、線程厘惦、響應(yīng)時(shí)間偷仿、并發(fā)量之間的關(guān)系是什么哩簿？**
關(guān)系圖.png
深入剖析響應(yīng)時(shí)間
多數(shù)人不能正確的去分析QPS，絕大部分的原因是不知道響應(yīng)時(shí)間具體消耗在什么資源上酝静，所以做不了正確的分析和判斷节榜。
所以自己先從響應(yīng)時(shí)間上去解釋，下列的響應(yīng)時(shí)間模型是我自己提煉的别智，未必是完全符合理論或者所有人的理解宗苍。
V1版本的響應(yīng)時(shí)間模型：響應(yīng)時(shí)間=請(qǐng)求傳輸時(shí)間+服務(wù)端處理時(shí)間+響應(yīng)傳輸時(shí)間
這個(gè)版本的服務(wù)端處理時(shí)間很籠統(tǒng)。
image.png
V2版本的響應(yīng)時(shí)間模型：****響應(yīng)時(shí)間=請(qǐng)求傳輸時(shí)間+內(nèi)部服務(wù)處理時(shí)間+外部服務(wù)處理時(shí)間+響應(yīng)傳輸時(shí)間
這個(gè)版本的服務(wù)端服務(wù)端處理時(shí)間拆分成兩部分
image.png
V3版本的響應(yīng)時(shí)間模型：****響應(yīng)時(shí)間=請(qǐng)求傳輸時(shí)間+服務(wù)內(nèi)部CPU運(yùn)算+服務(wù)內(nèi)部IO時(shí)間+外部服務(wù)處理時(shí)間+響應(yīng)傳輸時(shí)間
這個(gè)版本的服務(wù)端服務(wù)端處理時(shí)間進(jìn)一步拆分薄榛，拆分為不同的資源消耗
image.png
V4版本的響應(yīng)時(shí)間模型：****響應(yīng)時(shí)間=請(qǐng)求傳輸時(shí)間+服務(wù)內(nèi)部CPU運(yùn)算+服務(wù)內(nèi)部IO時(shí)間+內(nèi)部共享資源時(shí)間+外部服務(wù)處理時(shí)間+響應(yīng)傳輸時(shí)間
image.png
通過(guò)上面的分解讳窟，對(duì)響應(yīng)時(shí)間有個(gè)分解。最后把響應(yīng)時(shí)間的組成提煉為如下內(nèi)容
image.png
理解最優(yōu)線程數(shù)
最優(yōu)線程數(shù)的定義：使用最少的線程保持資源最大化的使用敞恋。
常有兩種情況：
當(dāng)線程數(shù)較少的時(shí)候,壓力情況下,可能造成線程資源不足,請(qǐng)求需要等待線程釋放后,才能處理丽啡。
當(dāng)線程數(shù)量較多的時(shí)候,線程自身也是需要消耗內(nèi)存資源,導(dǎo)致資源的浪費(fèi);同時(shí),線程較多的時(shí)候?qū)τ诰€程的調(diào)度和爭(zhēng)用也會(huì)影響性能。
對(duì)于最優(yōu)線程數(shù)常常有一些經(jīng)驗(yàn)或者理論上的值：
N+1:保證CPU在一定的阻塞情況下,也有可以運(yùn)行的線程進(jìn)?調(diào)度,進(jìn) 而保證CPU的運(yùn)?和利用
N-1:減少線程和線程調(diào)度間的爭(zhēng)用和調(diào)度
這些理論值常常是沒用的Ｓ裁ā２构俊！
理解響應(yīng)時(shí)間啸蜜、最優(yōu)線程數(shù)坑雅、CPU之間的關(guān)系
下面以一個(gè)例子來(lái)說(shuō)明這幾個(gè)的關(guān)系：假設(shè)一個(gè)請(qǐng)求的響應(yīng)時(shí)間是100ms，1個(gè)CPU衬横，1個(gè)線程的情況下推演霞丧。
image.png
一個(gè)請(qǐng)求的執(zhí)行快照如上圖。處理過(guò)程大概為：請(qǐng)求1綁定到線程1冕香，線程1綁定到cpu1蛹尝，cpu1上執(zhí)行100ms完成本次請(qǐng)求；
線程1繼續(xù)處理后續(xù)請(qǐng)求悉尾，比如請(qǐng)求2突那、請(qǐng)求3。
但是通過(guò)上面響應(yīng)時(shí)間模型可以得知构眯，一個(gè)請(qǐng)求的響應(yīng)時(shí)間不一定全部都是CPU耗時(shí)組成愕难，那么可能運(yùn)行的快照如下圖：
image.png
當(dāng)一個(gè)請(qǐng)求只有20ms在CPU上運(yùn)行，其余的80ms都在等待外圍的響應(yīng)惫霸，那么可以得出：線程1會(huì)在等待外圍80ms是阻塞猫缭；cpu1會(huì)在線程1阻塞時(shí)空閑。
那么為了讓CPU滿轉(zhuǎn)壹店，資源使用最大化猜丹，那么需要使用幾個(gè)線程呢？
image.png
通過(guò)上圖可以看出硅卢，當(dāng)有線程阻塞射窒，不斷的補(bǔ)充線程進(jìn)行執(zhí)行藏杖，就可以讓CPU滿轉(zhuǎn)。大概可以得出：最優(yōu)線程數(shù)=線程總時(shí)間/線程CPU執(zhí)行時(shí)間 * CPU核數(shù)脉顿。
似乎分析到這里蝌麸，應(yīng)該就快清晰的知道答案了，但是我們離的還遠(yuǎn)艾疟。下面進(jìn)一步分析
理解瓶頸資源：多資源情況下的線程調(diào)度分析
假設(shè)這樣的一個(gè)場(chǎng)景：
假設(shè)一個(gè)請(qǐng)求的服務(wù)器端處理時(shí)間為10ms来吩。其中cpu執(zhí)行5ms,4個(gè)CPU;數(shù)據(jù)庫(kù)操作時(shí)間5ms,應(yīng)用總共有2個(gè)可用連接
那么最后線程數(shù)是多少？如果按照上一步計(jì)算：最優(yōu)線程數(shù)=線程總時(shí)間/線程CPU執(zhí)行時(shí)間 * CPU核數(shù)=10ms/5ms * 4 = 8
上面的計(jì)算正確嗎蔽莱？為了解釋多資源情況下的線程調(diào)度弟疆，使用如下幾個(gè)快照分析。
把CPU時(shí)間劃分為5ms為一個(gè)時(shí)間段區(qū)域
1碾褂、第1個(gè)5ms快照的運(yùn)行情況如下：同時(shí)有4個(gè)線程在4個(gè)CPU上運(yùn)行，cpu處于滿轉(zhuǎn)历葛。
image.png
2正塌、第2個(gè)5ms快照的運(yùn)行情況如下：同時(shí)有4個(gè)線程在4個(gè)CPU上運(yùn)行，cpu處于滿轉(zhuǎn)恤溶；2個(gè)線程處理數(shù)據(jù)庫(kù)操作乓诽。
image.png
3、第3個(gè)5ms快照的運(yùn)行情況如下：同時(shí)有4個(gè)線程在2個(gè)CPU上運(yùn)行咒程，cpu處于滿轉(zhuǎn)鸠天；2個(gè)線程處理數(shù)據(jù)庫(kù)操作；其他被阻塞
image.png
4帐姻、第4個(gè)5ms快照的運(yùn)行情況如下：同時(shí)有4個(gè)線程在2個(gè)CPU上運(yùn)行稠集，cpu處于滿轉(zhuǎn)；2個(gè)線程處理數(shù)據(jù)庫(kù)操作饥瓷；其他被阻塞剥纷。
image.png
5、第5個(gè)5ms快照的運(yùn)行情況如下：同時(shí)有4個(gè)線程在2個(gè)CPU上運(yùn)行呢铆，cpu處于滿轉(zhuǎn)晦鞋；2個(gè)線程處理數(shù)據(jù)庫(kù)操作；其他被阻塞棺克。
image.png
通過(guò)上面的內(nèi)容可以看出悠垛，最優(yōu)線程數(shù)不僅僅取決于CPU核數(shù)，當(dāng)在多資源的情況下時(shí)：取決于資源短板娜谊。
這個(gè)類似于水桶原理：
image.png
說(shuō)了這么多确买，是不是感覺沒啥鳥用！
通過(guò)上面的推導(dǎo)纱皆，簡(jiǎn)單明了的告訴幾個(gè)理論上的公式
最優(yōu)線程公式
最優(yōu)線程數(shù)量=線程總時(shí)間/瓶頸資源時(shí)間 * 瓶頸資源并行數(shù)
一個(gè)線程1S可以處理的請(qǐng)求數(shù)
1000/線程總時(shí)間
QPS公式1
QPS =最優(yōu)線程數(shù)量* 1000/線程總時(shí)間
QPS公式2
QPS=1000/瓶頸資源時(shí)間 * 瓶頸資源并?行數(shù)
通過(guò)公式2可以看出：影響QPS的關(guān)鍵因素受限于瓶頸資源拇惋，所以大部分的性能優(yōu)化問題都是在解決：如何找出瓶頸資源周偎，如何優(yōu)化代碼對(duì)瓶頸資源的消耗。