簡介
- 發(fā)壓場景設計執(zhí)行(壓測建模-單系統(tǒng)-類-方法-數(shù)據(jù)存儲/多系統(tǒng)-業(yè)務場景保真)最住，-> 壓測平臺的實現(xiàn) -> 容量評估，流量預估
- 系統(tǒng)指標以及監(jiān)控觀測(全鏈路茂翔、發(fā)壓系統(tǒng))->觀測指標->確定系統(tǒng)瓶頸以及高并發(fā)下的場景可能的問題：
OOM(內(nèi)存溢出)
JVM GC情況(YGC悔政、FGC)
CPU 內(nèi)存 負載
線程池
IO
tcp連接數(shù) /tcp重傳、丟包谋国、隊列情況槽地、超時延遲、帶寬
可用率(業(yè)務配置) 分片情況 命中率
TP99/TP999...
各相關中間件芦瘾、存儲域的相應指標 - 系統(tǒng)架構環(huán)節(jié)闷盔，策略執(zhí)行情況 -> 了解系統(tǒng)的架構 網(wǎng)絡拓撲架構+ cdn +集群+分布式+mq(堆積)+緩存(redis，es旅急，hbase....) +db(慢查詢...)+鏈路之間影響 鏈路有多長輻射范圍有多廣逢勾，鏈路調用策略，整體鏈路(下水管道)對多個個機房的蓄水能力考驗
- 問題定位藐吮，性能優(yōu)化溺拱，流量大_數(shù)據(jù)大
- 流程規(guī)范的制定
Saas化能力分布
- 發(fā)壓框架(loadrunner逃贝，jmeter，ab迫摔，nGrinder沐扳，locust，各公司自研平臺)
- 指標收集：系統(tǒng)指標 網(wǎng)絡指標 全鏈路指標 聚合展示
- 壓測流程化 標準化(不影響 不污染)
- 壓測常態(tài)化 自動化 自助化
- 性能定位 非功能性
- 故障演練 應急方案
- 壓測報告自動化句占，數(shù)字化分析
- 流量收集沪摄，場景手機
平臺化對質量賦能
1. 壓測-質量保障-MSA-定量的檢驗(效率性、可靠性)
思考：
質量控制的標準行業(yè)標準自定義標準纱烘，質量提升的依據(jù)?
Ⅰ 壓測前
why 目標 盤點
- 為什么要壓測杨拐，壓測的話要做什么，壓測場景的設計擂啥，數(shù)據(jù)建模哄陶，鏈路的深度，鏈路的輻射哺壶， 關鍵鏈路梳理 -> 單系統(tǒng)內(nèi)部屋吨、多系統(tǒng)交互、全鏈路
- 了解目前的壓測流程以及使用技術山宾，服務瓶頸發(fā)現(xiàn)至扰，是否準備可靠，是否有可改進的地方
- 架構優(yōu)化的思路资锰，依據(jù)結果倒推
敢课。。台妆。翎猛。
常規(guī)步驟：
1胖翰、了解壓測背景接剩，制定整體壓測計劃，自上而下參與 準備：
流量預估萨咳、容量評估
1.1. 確定壓測目標: 整體系統(tǒng)qps/tps 細分[單系統(tǒng)(讀-寫) 類懊缺、接口、方法] 業(yè)務分布 性能需求確定
1.2. 溝通協(xié)調：與開發(fā)溝通培他，指定壓測指標（壓測結果驗收指標）---指標來源：容量預估/以往數(shù)據(jù)值鹃两，流量比例，或者之前宕機時的峰值舀凛，看是否能承載-> 監(jiān)控平臺俊扳，數(shù)據(jù)看板..
1.3. 腳本準備(成本，是否能達到邊際成本最大化)猛遍，數(shù)據(jù)建模-- 依據(jù)目標設計壓測場景馋记，讀寫組合号坡，接口組合，業(yè)務組合(部署機的業(yè)務部署架構)
測試數(shù)據(jù)整理梯醒，當然要考慮如何處理臟數(shù)據(jù)宽堆，數(shù)據(jù)脫敏，落入影子庫
1.4. 預計壓測中可能出現(xiàn)的問題茸习，避免到時措手不及畜隶，有排查思路，比如從之前壓測結果分析号胚，可能出現(xiàn)的問題（比如說上下游哪個系統(tǒng)之前出現(xiàn)過問題）籽慢，定位，及應急處理措施:
1.4.1 上下游依賴涕刚，強弱依賴嗡综，弱依賴可以使用開關
1.4.2 服務間通信問題，鏈路上rpc + mq杜漠，超時-重傳
1.4.3 負載均衡問題
1.4.4 容災問題
1.4.5 異常
1.4.6 業(yè)務識別
1.4.7. 壓測機器準備
1.4.8. 接口壓測標記
1.5 結束標準
2. 壓測中
單機壓測
鏈路壓測
A. 發(fā)壓開始极景，從哪個接口開始，還是所有接口一起驾茴，還是某幾個方法組合盼樟，還是對某一個業(yè)務進行鏈路壓，依據(jù)事先定義好的模型以及壓測計劃進行......
B. 監(jiān)控: cpu锈至、 內(nèi)存晨缴、 IO、 帶寬峡捡、 TP99击碗、 TP999 、tcp連接數(shù)们拙、 tcp重傳稍途、 qps、 tps砚婆、 可用率械拍、 負載、 分片情況装盯、 緩存命中率 gc...=>系統(tǒng)指標
C. 具體的指標值
D. 應急處理坷虑，熔斷、限流埂奈、降級迄损、隔離
E. 碰到的具體問題，根據(jù)運維監(jiān)控數(shù)據(jù)采集進行分析或者dump分析
鏈路指標 + 系統(tǒng)指標 + 網(wǎng)絡指標 + 故障注入 + 故障演練 +容量預估
限流降級熔斷
應用啟動順序
故障根源定位
容量評估
常見故障畫像：
1. Application/data：
1. 依賴超時账磺，依賴異常
2. 進程被殺
3. 配置錯誤芹敌，誤刪共屈，獲取超時
4. 心跳異常，比如過zk環(huán)境出現(xiàn)問題
5. 流控不合理党窜，下游調用策略問題(比如重復調用高)
6. 業(yè)務進程池滿拗引，中間件線程池滿
2. Virtualization/Storage/Networking
2.1 服務器宕機假死
2.2 磁盤滿，慢幌衣，壞
2.3 網(wǎng)絡抖動矾削，超時，DNS故障
3. Runtime | Middleware | O/S
3.1 負載均衡失效
3.2 CPU搶占
3.2 內(nèi)存搶占
3.3 數(shù)據(jù)庫宕機
3.4 數(shù)據(jù)同步延遲
3.5 上下文切換
3.6 數(shù)據(jù)庫連接滿
3.7 緩存熱點
3.8 緩存切流
F. 故障演練豁护，故障注入哼凯，鏈路上成員的職責和定位，系統(tǒng)外溝通處理楚里，系統(tǒng)內(nèi)的處理應急
G. 常見系統(tǒng)內(nèi)部問題：
- 單臺tps700多断部，應用cpu負載高
減少bean -map -json之間的數(shù)據(jù)轉換- 數(shù)據(jù)庫資源利用率高
數(shù)據(jù)庫cpu跑滿，但是qps不高班缎，可能是sql執(zhí)行耗費了時間蝴光，沒有按索引查找或者索引失效- nginx轉發(fā)配置問題
- 數(shù)據(jù)庫無壓力，應用增加多臺后tps不變
nginx轉發(fā)問題达址，導致time-wait- 增加服務器數(shù)量蔑祟， tps增長不明顯
服務器本身可能不是瓶頸，考慮是不是網(wǎng)絡問題沉唠，監(jiān)控網(wǎng)卡流量包疆虚，redis是否有報錯- 促銷
通過redis取數(shù)據(jù)，tps不高满葛，但cpu占80%径簿，說明程序內(nèi)部有大量序列化反序列化操作，可能是json序列化的問題- 應用及聯(lián)效應嘀韧，造成的雪崩
https://www.cnblogs.com/panchanggui/p/10330924.html
3. 壓測結束
數(shù)據(jù)收集篇亭，臟數(shù)據(jù)處理，整理問題乳蛾，分析問題暗赶，復盤鄙币，改善方案為下一次壓測準備肃叶，輸出性能壓測報告以及分析建議
依據(jù)流程規(guī)范，驗收所有壓測是否停止十嘿，環(huán)境恢復正常
壓測性能分析思路
了解服務的整體架構與設計(系統(tǒng)設計因惭，網(wǎng)絡拓撲圖)，熟悉各部分組成(包括硬件以及軟件層面)绩衷、以及部署架構
常見的幾個組成:
應用程序: 應用程序之間的通信行為蹦魔、磁盤或網(wǎng)絡上的數(shù)據(jù)訪問模式
操作系統(tǒng)
系統(tǒng)資源: cpu 內(nèi)存 磁盤IO利用率和延遲
服務器設備
網(wǎng)絡環(huán)節(jié)：網(wǎng)絡利用率
是否為混合部署
幾個指標：
RT(Response time): 用戶響應時間 = 服務器響應時間 + 網(wǎng)絡時間(網(wǎng)絡損耗激率，不同地域的網(wǎng)絡供應商，帶寬等)
傳輸數(shù)據(jù)量大勿决，帶寬上行乒躺，下載CPU分析：
檢查相關系統(tǒng)日志(自動化運維聚合分析)，web服務器日志低缩，DB日志嘉冒，分布式中間件，了解cpu狀態(tài)咆繁，是否被占用讳推，被什么服務占用
閥值: 期望系統(tǒng)的平均可用CPU不少于20%
步驟: 查出被什么服務占用
java程序可通過自帶的JVM命令工具:jstat、jmap玩般、JConsole
Mysql監(jiān)控工具:Spotlight银觅、 Monyog、命令行工具
a 計算任務重
b GC頻繁
c 上下文切換過多
d 大量異常填充棧信息
- 內(nèi)存分析
當可用的內(nèi)存太小坏为，系統(tǒng)進程會被阻塞中究驴，變得緩慢，失去響應匀伏，最后導致OOM從而引起應用程序被系統(tǒng)殺死纳胧，更嚴重導致系統(tǒng)重啟
虛擬內(nèi)存也是重要的指標，物理內(nèi)存不夠時帘撰，才進行內(nèi)存交換跑慕，把長時間不用的釋放掉，但是暫時放在虛擬內(nèi)存中
創(chuàng)建對象過多
- 網(wǎng)絡分析
網(wǎng)絡帶寬 響應時間 網(wǎng)絡延遲 阻塞 網(wǎng)絡抖動摧找，機房情況
- I/O
訪問應用離不開系統(tǒng)的磁盤數(shù)據(jù)讀寫核行，磁盤的I/O系統(tǒng)是系統(tǒng)中最慢的部分
日志記錄可能影響
- 可用率、負載蹬耘、TP99芝雪、TP999
常用性能測試分析調優(yōu)
1 性能分析調優(yōu)
2 基于單機的性能分析與調優(yōu)
3 基于業(yè)務流程優(yōu)化的性能調優(yōu)
4 基于結構(分布式，業(yè)務拆分)的性能分析與調優(yōu)
性能分析調優(yōu):
自底向上：通過監(jiān)控硬件及操作系統(tǒng)性能指標(CPU综苔、內(nèi)存惩系、磁盤、網(wǎng)絡等硬件資源的性能指標) 鏈路拓撲結構(SGM系統(tǒng)監(jiān)控)
自頂向下：通過生成負載來觀察被測試等系統(tǒng)性能如筛，比如響應時間堡牡、吞吐量
單機的性能分析與調優(yōu)
常見的系統(tǒng)架構: 用戶=>web=>application=>DB 以及中間件
性能分析流程:
Client(壓測機) ==> Web Server (Nginx、Tomcat杨刨、WebLogic) ==> OS( Linux晤柄、Windows) ==> 系統(tǒng)資源(CPU、內(nèi)存妖胀、磁盤芥颈、網(wǎng)絡) ==> AppServer(應用服務) ==> DB(數(shù)據(jù)庫服務器) 其它相關中間件
- 壓測機:
RT(響應時間)
TPS
CPU(cpu利用率惠勒、cpu負載)
Mem(物理內(nèi)存、虛擬內(nèi)存)
Disks Network(帶寬使用率爬坑，任務隊列長度)
- WebServer:
可用率纠屋、負載、TP99盾计、TP999
TCP連接數(shù) 可用netstat命令得到
Thread Pool巾遭，中間件建立的線程池、監(jiān)控線程狀態(tài)
JVM闯估， JVM性能指標灼舍，比如GC情況，HEAP使用情況- DB:
中間件與數(shù)據(jù)庫之間的建立的連接數(shù)及連接狀態(tài)
DB Time
一般硬件評價表現(xiàn)
- CPU利用率過高涨薪，常見原因：
計算量大骑素，比如遠算、連接查詢刚夺、數(shù)據(jù)統(tǒng)計
非等閑等待献丑，比如IO等待、資源利用
過多的系統(tǒng)調用侠姑，比如Java項目中寫日志- 內(nèi)存吃緊:
過多的頁交換與內(nèi)存泄漏
操作系統(tǒng)會把原內(nèi)存中的部分內(nèi)容釋放掉(移除或者寫入磁盤)创橄，然后把需要的內(nèi)容載入，這個過程就是頁交換- 磁盤繁忙莽红，數(shù)據(jù)讀寫頻繁
- 網(wǎng)絡流量過大
常見壓測時的問題妥畏，以及定位，應急處理
DB(數(shù)據(jù)庫)
系統(tǒng)的性能好壞很大一部分是由數(shù)據(jù)庫系統(tǒng)安吁、應用程序數(shù)據(jù)庫設計及如何使用數(shù)據(jù)庫來決定的
表設計優(yōu)化：避免null值醉蚁，使用INT而非BIGINT
梳理索引 ，explain鬼店，選擇合適的索引
1 讀寫分離
2 關鍵業(yè)務進行分區(qū)
3 常用查詢數(shù)據(jù)放入es网棍、hbase、redis
4 分庫分表
妇智。滥玷。。巍棱。
如何選擇合適的索引
- 選擇合適的數(shù)據(jù)類型
使用可存下數(shù)據(jù)的最小數(shù)據(jù)類型惑畴，整型<date,time<char,varchar<blob
使用簡單的數(shù)據(jù)類型，整型比字符處理開銷更小
使用合理的字段屬性長度拉盾，固定長度表更快桨菜。使用enum豁状，char而不是varchar
盡可能使用not null字段
- 選擇合適的索引列
查詢頻繁的列捉偏，where倒得，group by，order by夭禽，on...
where條件中出現(xiàn)的列
長度小的列霞掺，索引字段越小越好，數(shù)據(jù)庫的存儲單位是頁讹躯，一頁中能存下的數(shù)據(jù)越多越好菩彬，避免多次IO
- SQL語句優(yōu)化
Middleware(中間件)
JVM：監(jiān)控JVM堆內(nèi)存使用情況，包括GC屏率潮梯，線程狀態(tài);
FULL GC 操作是對堆空間進行全面回收骗灶，此時是停止響應用戶請求的，所以頻繁的FULL GC會影響響應時間
Thread pool: 通過netstat統(tǒng)計
DB connections pool : 通過netstat統(tǒng)計
Web Server
頁面控制與結果的渲染
關注問題:
a 頁面Size ：動態(tài)數(shù)據(jù)秉馏、CSS耙旦、JS、圖片等小小
b 不必要的數(shù)據(jù)傳輸
web服務性能優(yōu)化：
a 頁面靜態(tài)化萝究，減少DB負擔
b 減少頁面SIze
c 砍掉無用請求免都，無用數(shù)據(jù)傳輸
d 異步動態(tài)加載，后臺json傳輸
e 只能DNS以及CDN加速帆竹，讓響應數(shù)據(jù)離用戶更近绕娘，回避緩解網(wǎng)絡瓶頸
常見的優(yōu)化手段
Java代碼程序優(yōu)化（使用池子，減少重復的初始化操作栽连，連接初始化操作险领，日志落庫），串行-> 并行秒紧。事件編排舷暮，深拷貝優(yōu)化，去掉不必要的對象構造或調用
配置優(yōu)化(最佳配置比噩茄，如對應線程數(shù))
數(shù)據(jù)庫連接池優(yōu)化
線程優(yōu)化
業(yè)務流程優(yōu)化(增加用戶操作下面，button可點擊，答題頁面绩聘，限制請求次數(shù)沥割，合并請求次數(shù)..路徑變短，減少各種IO次數(shù))
集群結構(CDN優(yōu)化)凿菩、部署架構抽取優(yōu)化
消息體(數(shù)據(jù)壓縮机杜，減少序列化/反序列化，rpc衅谷，全量/增量)
中間件(kafka redis..椒拗，業(yè)務場景，讀寫)
網(wǎng)絡傳輸(網(wǎng)絡 帶寬 拓撲結構 延時 報文大小 減少交互次數(shù)-如原來需要4次rpc交互確認，是否可以批處理減少到2次蚀苛，重傳設定)
減少不必要的監(jiān)控節(jié)點在验，減少不必要數(shù)據(jù)內(nèi)容
物理機器(帶寬 拓撲結構 路徑)
不阻塞，均衡的分配
直播優(yōu)化
直播首開主要耗時： 獲取url堵未、dns解析腋舌、連接服務器、分析流信息
緩存dns解析渗蟹，在之前提前解析ip
壓測的專有名詞
參考地址：
https://blog.csdn.net/zuozewei/article/details/84983834
《块饺。。雌芽∈诩瑁》
