容量測試到底測什么一次對話理清同時在線和并發(fā)請求和同事討論容量測試發(fā)現(xiàn)很多人把同時在線和并發(fā)請求攪在一起。這篇把這段對話記錄下來幫你看清容量的本質(zhì)。文章目錄容量測試到底測什么一次對話理清同時在線和并發(fā)請求一、起點一個常見的判斷1.1 同事的初始判斷1.2 先搞清兩個概念二、如果只看同時在線容量確實可以非常大2.1 無狀態(tài)架構(gòu)在線用戶幾乎不花錢2.2 那有session的系統(tǒng)呢三、但是在線人數(shù)越高并發(fā)請求越高3.1 統(tǒng)計關(guān)系3.2 容量和并發(fā)是一個連續(xù)光譜3.3 一個實際例子四、并發(fā)請求的真正瓶頸在哪4.1 一個請求進來的真實開銷4.2 瓶頸清單4.3 一個并發(fā)請求的開銷五、容量測試到底測什么5.1 測的是第一個被打破的瓶頸5.2 各層監(jiān)控指標(biāo)5.3 常見場景六、總結(jié)6.1 三個結(jié)論6.2 一句話一、起點一個常見的判斷1.1 同事的初始判斷同事做政務(wù)系統(tǒng)要搞容量測試。他的判斷是容量測試應(yīng)該只和服務(wù)端內(nèi)存有關(guān)系吧session或者jwt也占用不了多少內(nèi)存容量應(yīng)該可以非常大。乍一看沒毛病——一個JWT字符串幾百字節(jié)一個session對象也就存點用戶信息內(nèi)存開銷確實不大。那同時在線幾萬人內(nèi)存也吃不了多少。容量瓶頸不該是內(nèi)存吧但這個判斷有一個隱藏的概念混淆。1.2 先搞清兩個概念同時在線容量并發(fā)請求含義多少用戶登錄著、在用系統(tǒng)服務(wù)器同一時刻在處理多少請求對服務(wù)器的直接壓力JWT幾乎為零session很小每個請求吃線程連接CPU瓶頸在哪幾乎沒有線程池/連接池/CPU/數(shù)據(jù)庫這是兩個完全不同的東西。很多開發(fā)者嘴上說著系統(tǒng)容量要支撐一萬用戶實際上擔(dān)心的是一萬用戶同時點按鈕服務(wù)器扛不扛得住——前者是容量問題后者是并發(fā)問題。二、如果只看同時在線容量確實可以非常大2.1 無狀態(tài)架構(gòu)在線用戶幾乎不花錢現(xiàn)在的系統(tǒng)基本都用JWT。用戶登錄后拿到一個tokentoken存在客戶端瀏覽器localStorage或Cookie。服務(wù)器不存任何東西。用戶登錄 → 服務(wù)器簽發(fā)JWT → 返回給客戶端 ↓ 用戶后續(xù)請求 → 帶上JWT → 服務(wù)器驗簽 → 處理請求 ↓ 請求結(jié)束 → 服務(wù)器什么都不留用戶拿不到token時在瀏覽頁面、填表單、看數(shù)據(jù)——這段時間對服務(wù)器來說這個用戶不存在。服務(wù)器不給他分配線程、不分配連接、不分配內(nèi)存。所以同時在線10萬人和100人對服務(wù)器來說沒區(qū)別——因為大部分在線用戶此刻沒有在發(fā)請求。2.2 那有session的系統(tǒng)呢有同事會說我們的系統(tǒng)用Tomcat的HttpSession每個用戶在服務(wù)端存一份session這不就占內(nèi)存了嗎算一筆賬。一個session里實際存什么數(shù)據(jù)大小估算用戶信息id、姓名、賬號~200字節(jié)機構(gòu)信息id、名稱~100字節(jié)角色列表幾個角色ID~50字節(jié)權(quán)限標(biāo)識如果是角色ID而非逐個權(quán)限~100字節(jié)合計不到1KB1000人在線session內(nèi)存不到1MB。10000人在線也就幾MB。跟服務(wù)器動輒幾個G的內(nèi)存比完全可以忽略。所以無論session還是JWT在線人數(shù)本身都不是瓶頸。同事最初的判斷方向是對的——容量確實可以非常大。三、但是在線人數(shù)越高并發(fā)請求越高3.1 統(tǒng)計關(guān)系到這里同事說那容量不是問題啊隨便扛。但這里有個統(tǒng)計關(guān)系一個系統(tǒng)在相關(guān)條件不變化同時在線用戶數(shù)量越多并發(fā)會越高。100個人在線同一時刻可能有5個人在點按鈕。10000個人在線同一時刻可能有500個人在點。在線人數(shù)上去了并發(fā)請求自然跟著上去。并發(fā)請求數(shù) ≈ 同時在線人數(shù) × 用戶活躍率 用戶活躍率 用戶在單位時間內(nèi)發(fā)起請求的概率不同系統(tǒng)的用戶活躍率差異極大系統(tǒng)類型用戶活躍率說明政務(wù)OA低大部分時間在看頁面、填表幾秒點一次電商日常中瀏覽、加購物車、搜索電商秒殺極高所有人同時點搶購按鈕即時通訊高收發(fā)消息、狀態(tài)同步幾乎一直在請求所以不能脫離用戶行為談容量。容量不是孤立的能掛多少在線用戶而是這些在線用戶產(chǎn)生的高并發(fā)服務(wù)器扛不扛得住。3.2 容量和并發(fā)是一個連續(xù)光譜容量測試 并發(fā)測試 能掛多少在線用戶 在線用戶產(chǎn)生的高并發(fā)扛不扛得住 ←————————————————————————————→ 統(tǒng)計橋梁用戶活躍率兩者不是對立的是同一條鏈路上的兩端。容量測試關(guān)注左端——系統(tǒng)能容納多少在線用戶。并發(fā)測試關(guān)注右端——這些用戶產(chǎn)生的請求高峰能不能扛。中間的橋梁就是用戶行為模式。3.3 一個實際例子某政務(wù)系統(tǒng)預(yù)期5000人同時在線。做容量測試時要算的不是5000個session占多少內(nèi)存而是5000人在線 × 用戶活躍率假設(shè)10%在同時操作 500個并發(fā)請求 ↓ Tomcat默認(rèn)maxThreads200 → 不夠要調(diào)大 數(shù)據(jù)庫連接池默認(rèn)20 → 遠遠不夠要調(diào)大 ↓ 這才是容量測試要回答的問題瓶頸不在5000人在線瓶頸在5000人產(chǎn)生的500個并發(fā)請求。四、并發(fā)請求的真正瓶頸在哪4.1 一個請求進來的真實開銷既然瓶頸在并發(fā)請求那一個請求到底吃服務(wù)器什么資源HTTP請求到達 ↓ Tomcat線程池分配線程maxThreads默認(rèn)200 ↓ 從連接池拿數(shù)據(jù)庫連接默認(rèn)8~20個 ↓ 執(zhí)行業(yè)務(wù)邏輯CPU計算、JWT驗簽、序列化 ↓ 查數(shù)據(jù)庫可能等待鎖、等待IO ↓ 返回響應(yīng) ↓ 釋放線程和連接每一環(huán)都可能先于內(nèi)存成為瓶頸。4.2 瓶頸清單瓶頸默認(rèn)上限說明線程池Tomcat默認(rèn)200200個并發(fā)請求就開始排隊跟內(nèi)存無關(guān)數(shù)據(jù)庫連接池Druid/HikariCP默認(rèn)8~20拿不到連接的請求要么等要么超時CPU看核數(shù)JWT驗簽、序列化、加解密、業(yè)務(wù)計算數(shù)據(jù)庫本身幾百~上千并發(fā)鎖競爭、慢查詢數(shù)據(jù)庫比應(yīng)用服務(wù)器先扛不住內(nèi)存看配置session/JWT確實占不了多少4.3 一個并發(fā)請求的開銷不要把一個用戶在線和一個請求處理搞混資源一個在線用戶空閑一個正在處理的請求線程無一個線程棧空間512KB~1MB數(shù)據(jù)庫連接無一個連接連接對象會話狀態(tài)內(nèi)存session/JWT ~1KB結(jié)果集、序列化緩沖、臨時對象CPU無JWT驗簽、業(yè)務(wù)計算、序列化1000個并發(fā)請求光線程棧就吃掉1GB內(nèi)存。而且線程切換的CPU開銷比內(nèi)存更致命。所以容量可以非常大這句話對了一半——在線用戶的容量確實很大但他們產(chǎn)生的并發(fā)請求打到的瓶頸不在內(nèi)存在別的地方。五、容量測試到底測什么5.1 測的是第一個被打破的瓶頸容量測試不是應(yīng)用服務(wù)器內(nèi)存能掛多少session而是從用戶請求到數(shù)據(jù)庫返回這條鏈路上哪個環(huán)節(jié)最先斷。不斷加壓觀察哪個指標(biāo)先異常逐漸增加在線用戶數(shù)或直接加并發(fā)請求 ↓ 監(jiān)控每一層的指標(biāo) ↓ 第一個先撐不住的環(huán)節(jié) 系統(tǒng)的真實容量上限5.2 各層監(jiān)控指標(biāo)層次監(jiān)控什么異常表現(xiàn)應(yīng)用服務(wù)器CPU、內(nèi)存、線程數(shù)、GCCPU持續(xù)80%、頻繁Full GCWeb容器活躍線程數(shù)、請求隊列長度線程滿、請求排隊超時連接池活躍連接數(shù)、等待連接數(shù)連接耗盡、請求等待數(shù)據(jù)庫活躍會話數(shù)、鎖等待、慢SQL鎖沖突、SQL變慢網(wǎng)絡(luò)帶寬、連接數(shù)、丟包響應(yīng)時間飆升5.3 常見場景場景最先斷的環(huán)節(jié)解法方向政務(wù)OA數(shù)據(jù)庫連接池默認(rèn)太小調(diào)大連接池上限查詢密集型數(shù)據(jù)庫慢SQL加索引、優(yōu)化SQL、讀寫分離計算密集型應(yīng)用服務(wù)器CPU加機器、異步化秒殺類數(shù)據(jù)庫行鎖隊列削峰、緩存六、總結(jié)6.1 三個結(jié)論同時在線和并發(fā)請求是兩個概念——在線用戶的內(nèi)存開銷確實很小session或JWT都不到1KB可以忽略但在線人數(shù)越高并發(fā)越高——兩者通過用戶活躍率關(guān)聯(lián)不能脫離用戶行為談容量瓶頸永遠在并發(fā)請求層——線程池、連接池、CPU、數(shù)據(jù)庫這些才是容量上限的真正決定因素6.2 一句話容量測試不是測能掛多少用戶是測這些用戶一起點的時候哪個環(huán)節(jié)先斷。