我們經(jīng)常需要對(duì)程序進(jìn)行壓測(cè)，怎么壓才合適？壓到什么樣才說(shuō)明應(yīng)用達(dá)到了性能瓶頸？用什么指標(biāo)來(lái)衡量才合適？一些指標(biāo)異常又說(shuō)明了什么？我們又該怎么樣去查問(wèn)題？這些都是壓測(cè)時(shí)我們需要關(guān)注的。
按照大項(xiàng)劃分，個(gè)人將性能指標(biāo)分為下面幾個(gè)大項(xiàng)：
一、基本性能指標(biāo) QPS 和 RT
這是測(cè)試過(guò)程中最基本的指標(biāo)，也是我們主要需要關(guān)注的兩項(xiàng)。QPS 是指系統(tǒng)每秒處理的請(qǐng)求個(gè)數(shù)（query per second）。RT 指一個(gè)請(qǐng)求發(fā)出后系統(tǒng)的響應(yīng)時(shí)間（reaction time）。區(qū)別下 QPS 和 TPS（Transactions per Second），他倆很像但是不是一個(gè)東西。TPS 是指每秒處理的事務(wù)數(shù)，一個(gè)事務(wù)是指一個(gè)客戶機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過(guò)程。舉個(gè)例子比如某個(gè)接口里面有很多項(xiàng)操作，這時(shí)往往用 QPS 是不準(zhǔn)確的，因?yàn)闇?zhǔn)確來(lái)說(shuō) QPS 針對(duì)的是 Query，是詢問(wèn)，如單獨(dú)的數(shù)據(jù)庫(kù)讀甚至是寫都可以叫一個(gè)詢問(wèn)，但當(dāng)接口里有多個(gè)操作，本質(zhì)上調(diào)用一次產(chǎn)生一次事務(wù)，同時(shí)里面有許多 Query。所以 QPS 往往會(huì)比 TPS 大些。如果針對(duì)應(yīng)用來(lái)說(shuō)我們調(diào)用一次內(nèi)部邏輯又不可見不知道里面有多少操作，這時(shí) TPS 和 QPS 常常區(qū)分不開的，建議用 TPS 來(lái)衡量好些。
這里還要提到一個(gè)重要概念：最佳線程數(shù)量，是指剛好消耗完服務(wù)器瓶頸資源的臨界線程數(shù)。 最佳線程數(shù)和 QPS、RT 是有一定關(guān)系的，這個(gè)線程數(shù)需要在壓測(cè)過(guò)程中不斷地去調(diào)整（一般從小到大來(lái)調(diào)，剛開始可能10個(gè)），努力去接近我們?cè)O(shè)定預(yù)期的性能測(cè)試極限。這個(gè)線程數(shù)和請(qǐng)求量正比關(guān)系，但是一定不要認(rèn)為線程數(shù)少請(qǐng)求量就小。一般線程數(shù)設(shè)置8-10個(gè)左右，QPS 就可以達(dá)到 500 多了。舉個(gè)例子，一個(gè)線程一秒內(nèi)可以發(fā)送 N 個(gè)請(qǐng)求其實(shí)也是固定的，那增加我們的線程個(gè)數(shù)，比如現(xiàn)在我們有 M 個(gè)線程，那每秒理論上可以發(fā) M*N 個(gè)請(qǐng)求，不考慮應(yīng)用瓶頸，那應(yīng)用每秒 QPS 就可以達(dá)到 M*N，當(dāng)然有瓶頸情況下 QPS 到一定程度就不會(huì)再提升了，因?yàn)橐粋€(gè)應(yīng)用每秒能處理的請(qǐng)求就那么多，每處理一個(gè)請(qǐng)求響應(yīng)時(shí)間 RT 是有限的，當(dāng)不斷請(qǐng)求過(guò)來(lái)產(chǎn)生堆積，響應(yīng)時(shí)間上升了，還會(huì)導(dǎo)致 QPS 的下降。
先看看這三者的關(guān)系，QPS = 1000*線程數(shù)量/RT。QPS 單位是秒，RT 單位是毫秒，所以有一個(gè)單位換算分子乘以了1000。QPS 和 RT 成反比，當(dāng)超過(guò)最佳線程數(shù)，會(huì)導(dǎo)致資源競(jìng)爭(zhēng)加劇，同時(shí)響應(yīng)時(shí)間也會(huì)增加，QPS 下降。
那么問(wèn)題來(lái)了，如何找到最佳線程數(shù)？最土但是最實(shí)用的方法是，逐步壓測(cè)，不斷地調(diào)整線程數(shù)來(lái)觀察系統(tǒng)的負(fù)載。
二、數(shù)據(jù)庫(kù)指標(biāo)
很多應(yīng)用的瓶頸是在數(shù)據(jù)庫(kù)指標(biāo)。比如連接數(shù)、數(shù)據(jù)庫(kù)的操作監(jiān)控等等。
三、性能指標(biāo)
性能指標(biāo)是針對(duì)性能機(jī)器的，最佳線程數(shù)調(diào)整的監(jiān)控項(xiàng)就是根據(jù)這個(gè)指標(biāo)來(lái)的。這底下有很多東西，羅列一下：CPU使用率、JVM堆棧使用情況、GC/FGC 次數(shù)、Load指標(biāo)、網(wǎng)絡(luò)延時(shí)。
3.1 CPU 使用率
一般性能測(cè)試指標(biāo)，CPU 使用率小于 75% 比較合適。通過(guò)指令：cat /proc/stat 可以查看。第一行CPU是所有CPU數(shù)據(jù)總和，CPU0~3表示各個(gè)CPU數(shù)據(jù)。其中第一列為從系統(tǒng)啟動(dòng)開始累計(jì)到當(dāng)前時(shí)間，用戶態(tài)的CPU時(shí)間（單位：jiffies，1 jiffies = 0.01秒）。
3.2 JVM 堆棧使用情況
對(duì)于我們的應(yīng)用來(lái)說(shuō)，一般會(huì)配置 JVM 的，所以對(duì)于應(yīng)用來(lái)說(shuō)，看機(jī)器的整體內(nèi)存是沒有意義的，我們更要關(guān)注的是堆棧的使用情況，關(guān)注點(diǎn)在已用堆信息。
3.3 GC / FGC 次數(shù)
在性能測(cè)試過(guò)程中不能出現(xiàn)因?yàn)镕GC 的產(chǎn)生導(dǎo)致響應(yīng)時(shí)間急劇升高的現(xiàn)象，否則壓測(cè)是不正確的。盡量保證 FGC 的出現(xiàn)次數(shù)是0，如果出現(xiàn)看看它的運(yùn)行時(shí)間，要確保是 FGC 產(chǎn)生運(yùn)行時(shí)間足夠短，否則就可以提Bug了。GC 產(chǎn)生是比較正常的，也要確保它的產(chǎn)生時(shí)間保持在比較低的水平。
3.4 Load 指標(biāo)
Load 是 CPU 的負(fù)載，它所包含的信息不是 CPU 的使用率狀況，二是在一段時(shí)間內(nèi) CPU 正在處理以及等待CPU處理的進(jìn)程數(shù)之和的統(tǒng)計(jì)信息，也就是CPU使用隊(duì)列的長(zhǎng)度的統(tǒng)計(jì)信息。一般測(cè)試時(shí)它的指標(biāo)是Load<CPU的核數(shù)*2。通過(guò)指令：cat /proc/loadavg 可以查看。五個(gè)數(shù)字分別是一分鐘平均負(fù)載，5分鐘內(nèi)平均負(fù)載，15分鐘內(nèi)平均負(fù)載，采樣時(shí)刻運(yùn)行隊(duì)列的任務(wù)數(shù)目，系統(tǒng)中活躍任務(wù)數(shù)目，最大 pid 值（包括線程）。
3.5 網(wǎng)絡(luò)延時(shí)
常用應(yīng)用服務(wù)器ping數(shù)據(jù)庫(kù)，看看數(shù)據(jù)庫(kù)延時(shí)是多少。
四、整體測(cè)試指標(biāo)
RT（Response Time）<= 200ms，根據(jù)業(yè)務(wù)有所不同，只讀的可能小于 10ms。
Load 服務(wù)器負(fù)載 <= CPU Core
CPU <= 75%
壓測(cè)失敗率 <= 0.2%
此外還要關(guān)注下方法耗時(shí)。
作者：FlySheep_ly
鏈接：http://www.itdecent.cn/p/de1e9f56f61e
來(lái)源：簡(jiǎn)書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
