1干发、背景
1.1铐然、項目背景
隨著APP-DDB在線用戶數(shù)的不斷增長沥阳，也為了減少服務(wù)器的使用臺數(shù)桐罕，降低成本功炮，需要對DDB的性能進一步優(yōu)化薪伏。
1.2、性能目標(biāo)
1.2.1塘淑、根據(jù)DDB的業(yè)務(wù)特性存捺，測試當(dāng)前系統(tǒng)的單接口最大容量。
1.2.2具滴、根據(jù)業(yè)務(wù)比例設(shè)計容量場景，充分利用當(dāng)前資源趋艘，找到當(dāng)前系統(tǒng)的性能瓶頸，并優(yōu)化搓萧，以達到系統(tǒng)的最佳運行狀態(tài)瘸洛。
1.2.3那伐、根據(jù)穩(wěn)定性場景罕邀，判斷當(dāng)前系統(tǒng)可支持的系統(tǒng)最大累加容量。
1.2.4阵具、根據(jù)異常場景阳液，判斷當(dāng)前系統(tǒng)中的異常對性能產(chǎn)生的影響。
2鹰溜、測試范圍
2.1曹动、需要測試的特性
只模擬從redis讀取指令，并且向筆端發(fā)送指令的接口容量測試贡必。
2.2仔拟、不需要測試的特性
不驗證從APP端操作下載等功能->java服務(wù)->redis->消息服務(wù)器的完整流程的接口容量測試科侈。
3兑徘、測試準(zhǔn)則
3.1、啟動準(zhǔn)則
3.1.1崭闲、確定系統(tǒng)邏輯架構(gòu)和部署架構(gòu)與生產(chǎn)一致刁俭。
3.1.2、確定基礎(chǔ)數(shù)據(jù)和生產(chǎn)一致或按模型縮放如孝。
3.1.3、確定業(yè)務(wù)模型可以模擬生產(chǎn)真實業(yè)務(wù)茁瘦。
3.1.4甜熔、環(huán)境準(zhǔn)備完畢腔稀，包括：
a. 功能驗證通過弱左。
b. 各組件基礎(chǔ)參數(shù)梳理并配置正確拆火。
c. 壓力機到位币叹，并部署完畢颈抚。
d. 網(wǎng)絡(luò)配置正確驱富，連接通暢匹舞，可以滿足壓力測試需求叫榕。
3.1.5晰绎、測試計劃、方案評審?fù)戤叀?br>
3.1.6锄弱、架構(gòu)組、運維組掸鹅、開發(fā)組拦赠、測試組及相關(guān)專家人員到位句携。
3.2削咆、結(jié)束準(zhǔn)則
3.2.1蠢笋、達到項目要求的性能需求指標(biāo)昨寞。
3.2.2、關(guān)鍵性能瓶頸已解決熟史。
3.2.3、完成性能測試報告和性能調(diào)優(yōu)報告限寞。
3.3、暫停/再啟動準(zhǔn)則
3.3.1玫霎、暫停規(guī)則
a、系統(tǒng)環(huán)境變化：舉例：系統(tǒng)主機硬件損壞措伐、網(wǎng)絡(luò)傳輸時間超長亮蛔、壓力發(fā)生器出現(xiàn)損壞、系統(tǒng)主機因別的原因需升級暫停等敷鸦。
b钞螟、測試環(huán)境受到干擾洞焙，比如服務(wù)器被臨時征用澡匪，或服務(wù)器的其他使用會對測試結(jié)果造成干擾疑苔。
c、需要調(diào)整測試環(huán)境資源薪贫，如操作系統(tǒng)鳍贾、數(shù)據(jù)庫參數(shù)等骑科。
d梳码、該測試機型無法達到規(guī)劃指標(biāo)要求。
e濒蒋、出現(xiàn)測試風(fēng)險中列出的問題沪伙。
3.3.2围橡、再啟動規(guī)則
a翁授、測試中發(fā)現(xiàn)問題得以解決。
b贮配、測試環(huán)境恢復(fù)正常。
c圆存、測試風(fēng)險中出現(xiàn)的問題已解決辽剧。
d怕轿、環(huán)境調(diào)整完畢。
4、業(yè)務(wù)模型/性能指標(biāo)/資源利用率指標(biāo)
4.1邻奠、業(yè)務(wù)模型/測試模型
接口1：登錄 - /login - 業(yè)務(wù)比例占5%
接口2：下載 - /download - 業(yè)務(wù)占比10%
接口3：播單 - /playlist - 業(yè)務(wù)占比15%
4.2蒙畴、業(yè)務(wù)指標(biāo)/性能指標(biāo)
接口1：登錄 - /login - 目標(biāo)TPS - TPS標(biāo)準(zhǔn)方差 - 響應(yīng)時間 - 響應(yīng)時間方差
接口2：下載 - /download - 目標(biāo)TPS - TPS標(biāo)準(zhǔn)方差 - 響應(yīng)時間 - 響應(yīng)時間方差
接口3：播單 - /download - 目標(biāo)TPS - TPS標(biāo)準(zhǔn)方差 - 響應(yīng)時間 - 響應(yīng)時間方差
4.3碑隆、資源利用率指標(biāo)
cpu idle 30%
memory 無劇烈抖動或嚴(yán)重飆升（無內(nèi)存抖動休玩、無內(nèi)存泄漏牧抽、無oom）
5阐肤、系統(tǒng)架構(gòu)圖
5.1、系統(tǒng)技術(shù)棧
Java
PHP
redis
gitlab
5.2衫画、系統(tǒng)邏輯架構(gòu)圖
APP->Java服務(wù)->Redis->PHP服務(wù)->DDB
5.3费奸、系統(tǒng)部署架構(gòu)圖
無
6微服、性能實施前提條件
6.1、硬件環(huán)境
6.1.1丛肮、起壓環(huán)境：4核8G 500G （使用free -h 查看內(nèi)存）；測試工具的安裝與調(diào)試
6.1.2节值、被壓環(huán)境：4核8G 500G ；基礎(chǔ)環(huán)境已搭建匿乃，代碼已部署
6.1.3、線下線上機器部署情況要有一定比例 宛徊，比如1/2，1/4
6.2逻澳、工具準(zhǔn)備
6.2.1闸天、測試工具
a、jmeter：獲取壓測數(shù)據(jù)
b斜做、influxdb：采集數(shù)據(jù)到數(shù)據(jù)庫
c、grafana：展示數(shù)據(jù)
6.2.2瓤逼、監(jiān)控工具
阿里云監(jiān)控
6.3笼吟、數(shù)據(jù)準(zhǔn)備
6.3.1、數(shù)據(jù)量的準(zhǔn)備：一定要按生產(chǎn)等比例縮放或者和生產(chǎn)數(shù)據(jù)一致來準(zhǔn)備數(shù)據(jù)（1抛姑、數(shù)據(jù)量過多或者數(shù)據(jù)量過少或者數(shù)據(jù)量不均勻赞厕，無法測出系統(tǒng)正常的容量。2定硝、要根據(jù)實際的業(yè)務(wù)去準(zhǔn)備測試數(shù)據(jù)皿桑，比如釘釘打卡，每天登錄10次蔬啡，打卡10次诲侮，肯定是不符合業(yè)務(wù)邏輯的；再比如商城購買商品箱蟆，每個用戶都購買同一款商品沟绪，或者每個用戶循環(huán)購買同一款商品，肯定是不符合業(yè)務(wù)邏輯的空猜。）
a绽慈、登錄數(shù)據(jù)：1W
b恨旱、下載數(shù)據(jù)：10W
c、播單數(shù)據(jù)：10W
6.3.2坝疼、數(shù)據(jù)準(zhǔn)備的方式：
a搜贤、數(shù)據(jù)庫
b、redis
c钝凶、csv
7仪芒、性能設(shè)計
7.1、題外話：100個線程循環(huán)100次和1000個線程循環(huán)10次有什么區(qū)別耕陷？
壓測是服務(wù)器對線程的處理能力掂名。假設(shè)CPU每秒處理10000個線程。
a哟沫、設(shè)置100個線程循環(huán)100次饺蔑，并發(fā)時間設(shè)置為1s，CPU剛好可以處理過來南用，吞吐量是137膀钠，不會影響服務(wù)器的性能掏湾。
b裹虫、設(shè)置1000個線程循環(huán)10次，并發(fā)時間設(shè)置為1s, CPU處理不過來融击，可能會導(dǎo)致線程出現(xiàn)排隊的現(xiàn)象筑公，吞吐量是83，影響服務(wù)器的性能尊浪。
7.2匣屡、場景執(zhí)行策略
7.2.1、加壓方式：階梯加壓和高并發(fā)加壓
階梯加壓：通過不斷的并發(fā)加壓拇涤，驗證不同并發(fā)下服務(wù)的處理能力捣作。
階梯加壓的兩個特點：連續(xù)和階梯。
高并發(fā)加壓：高并發(fā)加壓鹅士，驗證流量高峰時服務(wù)的處理能力券躁。
高并發(fā)加壓的適用場景：秒殺、限流等掉盅。說到秒殺場景也拜，有人覺得用大線程并發(fā)是合理的，其實這屬于認識上的錯誤趾痘。因為即使線程數(shù)增加得再多慢哈，對已經(jīng)達到 TPS 上限的系統(tǒng)來說，除了會增加響應(yīng)時間之外永票，并無其他作用卵贱。
下面來驗證一下滥沫，階梯加壓和高并發(fā)加壓有什么區(qū)別？（壓了一下键俱，不敢把公司服務(wù)器壓到TPS上限佣谐。知道有這么個事兒就可以了。）
a方妖、設(shè)置1000個線程狭魂，循環(huán)次數(shù)不限，并發(fā)時間設(shè)置為0：
b党觅、設(shè)置30秒啟動1000個線程雌澄，持續(xù)3分鐘：
c、設(shè)置60秒啟動1000個線程杯瞻，持續(xù)3分鐘:
7.2.2镐牺、場景遞增策略一定要滿足兩個條件：遞增+連續(xù)
7.2.3、業(yè)務(wù)場景：
a魁莉、基準(zhǔn)場景：把單接口或者單業(yè)務(wù)壓到最大TPS睬涧，然后來分析單接口和單業(yè)務(wù)的瓶頸點在哪里。
b旗唁、容量場景：按業(yè)務(wù)比例進行壓測畦浓。容量場景的最大TPS是指最大的穩(wěn)定TPS。
c检疫、穩(wěn)定性場景：兩個關(guān)鍵點：穩(wěn)定性場景的時長&用多大的TPS來執(zhí)行讶请。在執(zhí)行穩(wěn)定性場景時，完全可以用最大的穩(wěn)定 TPS 來運行屎媳，只要覆蓋了運維周期之內(nèi)的業(yè)務(wù)容量即可夺溢。
d、異常場景：宕主機烛谊、宕網(wǎng)卡风响、宕容器、宕應(yīng)用等丹禀。
7.3状勤、監(jiān)控設(shè)計：全局監(jiān)控+定向監(jiān)控
8、項目組織架構(gòu)
8.1湃崩、性能項目經(jīng)理
8.2荧降、性能腳本工程師：負責(zé)編寫性能測試腳本和場景執(zhí)行
8.3、性能分析工程師：負責(zé)分析性能場景執(zhí)行過程中遇到的性能瓶頸
8.4攒读、架構(gòu)師：負責(zé)支持性能分析
8.5朵诫、運維工程師：負責(zé)支持性能分析
8.6、業(yè)務(wù)方：確定性能項目的業(yè)務(wù)級需求
8.7薄扁、老板：理智的老板負責(zé)協(xié)調(diào)支持剪返；不理智的老板負責(zé)指手畫腳的搗亂
9废累、成果輸出
9.1、過程性輸出
9.1.1脱盲、腳本
9.1.2邑滨、場景執(zhí)行結(jié)果
9.1.3、監(jiān)控結(jié)果
9.1.4钱反、問題記錄
9.2掖看、結(jié)果輸出
9.2.1、性能項目測試報告
a面哥、性能結(jié)果報告一定要有結(jié)論哎壳，而不是給出一堆“資源使用率是多少”、“TPS 是多少”尚卫、“響應(yīng)時間是多少”這種描述類的總結(jié)語归榕。你想想，性能結(jié)果都在這個報告中了吱涉，誰還看不見怎么滴刹泄？還要你復(fù)述一遍嗎？我們要給出“當(dāng)前系統(tǒng)可支持 XXX 并發(fā)用戶數(shù)怎爵，XXX 在線用戶數(shù)”這樣的結(jié)論特石。
b、一定不要用“可能”疙咸、“或許”县匠、“理應(yīng)”這種模棱兩可的詞，否則就是在赤裸裸地耍流氓撒轮。
c、性能結(jié)果報告中要有對運維工作的建議贼穆，也就是要給出關(guān)鍵性能參數(shù)的配置建議题山，比如線程池、隊列故痊、超時等顶瞳。
d、性能結(jié)果報告中要有對后續(xù)性能工作的建議愕秫。
9.2.2慨菱、性能調(diào)優(yōu)報告：調(diào)優(yōu)報告才是整個性能項目的精華，調(diào)優(yōu)報告中一定要記錄下每一個性能問題的問題現(xiàn)象戴甩、分析過程符喝、解決方案和解決效果。
10甜孤、項目風(fēng)險分析
10.1协饲、業(yè)務(wù)層的性能需求不明確
10.2畏腕、環(huán)境問題
10.3、數(shù)據(jù)問題
10.4茉稠、業(yè)務(wù)模型不準(zhǔn)確
10.5描馅、團隊間溝通協(xié)作困難
10.6、瓶頸分析不到位而线，影響進度
10.7铭污、硬件資源有限
10.8、項目時間不可控膀篮，因為出了問題况凉，并沒有人支持，只能自己搞各拷。
參考：高樓老師的課程
