性能測試之問題定位分析

1、性能測試之問題定位分析主講人：唐曉文培訓大綱 性能測試基礎知識回顧 性能測試加壓各階段 性能問題排查方法 性能測試常見問題 案例講解：能耗監(jiān)控系統(tǒng) 其他：性能測試思維誤區(qū) 其他：性能測試工程師要具備的技能 說明：為方便解說此次培訓所有例子均為單機web項目http+java+Tomcat+Mysql結構知識回顧：Http請求瀏覽器一次請求的執(zhí)行過程：1、瀏覽器（查詢DNS）解析出域名IP地址和端口號。N12、瀏覽器發(fā)起到該IP地址端口的連接，3次握手建立連接。N13、瀏覽器發(fā)送一條http報文到服務器端。N14、服務器端接收到報文后根據(jù)路徑參數(shù)執(zhí)行相應程序，程序連接數(shù)據(jù)庫獲取數(shù)據(jù)，組裝成響應報

2、文內(nèi)容，發(fā)送給瀏覽器。N2+N3+N45、瀏覽器獲得服務器傳回的響應報文加載展現(xiàn)。！6、瀏覽器邊加載邊解析html頁面文件請求獲取其他資源。7、服務器相應返回其他資源。8、瀏覽器解析展現(xiàn)。9、瀏覽器關閉連接。知識回顧：了解工具準確模擬場景 Jmeter的幾個關鍵參數(shù)： 1）線程組的Ramp-up Period 2）Http采樣器的Use KeepAlive 3）從HTML文件獲取內(nèi)含的資源 4）緩存HTTP Cache Manager 5）設置集合點Synchronizing Timer 6）定時器（思考時間） 7）參數(shù)化性能測試加壓各階段一個正常的系統(tǒng)在不斷加壓的過程，應該經(jīng)歷下面幾個階段：

3、第一第一階段：階段：并發(fā)用戶逐漸增加，系統(tǒng)的TPS（每秒處理事務筆數(shù)）逐步增大，直到達到最大值，這一階段事務的響應時間不會有太大變化，會非常穩(wěn)定；第二第二階段：階段：并發(fā)用戶繼續(xù)增加，TPS基本維持在最大值不變，但響應時間將會逐步變長。第三第三階段：階段：并發(fā)用戶繼續(xù)增加，TPS將會有少量下降（20%以內(nèi)），但是決不能快速急劇下降，響應時間仍會逐步變長。本階段可以拒絕服務，但是不能宕機、報錯。加壓完成后，所有占用的CPU/內(nèi)存/IO資源均得到釋放?！竞螘r停止加壓何時停止加壓】！1、加壓到程序報錯、響應時間太長、資源占用過高、宕機。2、加壓達到單機最大極限請求被拒絕是可以接受的。 （聯(lián)機系統(tǒng)To

4、mcat單機默認配置600-800并發(fā)）性能問題排查方法 Ping網(wǎng)絡速度，查看各服務器資源情況。 排查單次訪問執(zhí)行是否存在性能問題FireBug。 響應時間過長如何排查？先分析響應時間，再按網(wǎng)速-內(nèi)容大小-數(shù)據(jù)庫-程序報錯-業(yè)務處理邏輯順序排查。涉及到第三方接口服務：Mock第三方接口再測。 機器負載過高如何排查？先定位問題范圍再細查： 1）應用服務器：查看連接數(shù)、查看服務器日志、查看業(yè)務處理邏輯、監(jiān)控JVM運行（jvisualvm.exe） 2）數(shù)據(jù)庫：查看連接數(shù)、抓出最耗時SQL、Explain分析SQL語句、優(yōu)化SQL/索引。性能問題排查使用到的工具 查看監(jiān)控tomcat性能：jvis

5、ualvm.exe或自帶監(jiān)控 查看監(jiān)控IIS連接數(shù)：運行perfmon.msc，添加計數(shù)器Web Service里的Current Connection 查看mysql數(shù)據(jù)庫運行情況：SHOW PROCESSLIST 查看mysql數(shù)據(jù)庫連接情況： show status like Threads%; 找出mysql最慢sql：開啟慢查詢?nèi)罩?Oracle查找最近執(zhí)行過的語句：select * from v$sqlarea t order by t.LAST_ACTIVE_TIME desc; 分析sql執(zhí)行計劃：explain sql語句性能問題排查方法論總結自底向上的分析方法：即從硬件&a

6、mp;網(wǎng)絡-操作系統(tǒng)-數(shù)據(jù)庫-應用程序-業(yè)務需求邏輯。先仔細檢查硬件、網(wǎng)絡層面相對簡單的問題，再深入到系統(tǒng)軟件和應用軟件相對復雜的領域。問題實踐 1、能耗監(jiān)控平臺單次查詢電表歷史讀數(shù)響應很慢 2、加壓到500并發(fā)時應用程序cpu占用率10%，數(shù)據(jù)庫cpu占用率100% 3、大并發(fā)下負載均衡雙機部署web網(wǎng)站訪問很慢怎么測？怎么排查？可能的問題有哪些？常見的性能問題有哪些？響應時間過長Cpu占用率100%內(nèi)存占用率100%程序掛了測試腳本運行報錯了常見性能問題 數(shù)據(jù)庫：SQL執(zhí)行耗時耗資源、無索引。 程序：代碼運行慢、拋異常、內(nèi)存溢出。 中間件配置：線程池設置過小、內(nèi)存設置過小。 網(wǎng)絡：交換機、

7、防火墻、內(nèi)外網(wǎng)。 硬件：存儲設備、機器硬件問題。70%的問題來自于數(shù)據(jù)庫的問題來自于數(shù)據(jù)庫20%來自于程序本身來自于程序本身10%來自于配置優(yōu)化來自于配置優(yōu)化案例講解：能耗監(jiān)控系統(tǒng)案例講解：測試需求分析測試策略 負載測試 穩(wěn)定性測試 測試對象 采用何種技術、協(xié)議、工具 測試對象的業(yè)務邏輯 測試目的、指標 性能驗收測試 平臺2000并發(fā)、10萬臺設備 重點測試對象、優(yōu)先級 大數(shù)據(jù)測試 案例講解：發(fā)現(xiàn)的問題 1、tomcat線程池配置最大連接數(shù)100 2、Mysql數(shù)據(jù)庫連接池連接數(shù)最大30 3、sql語句優(yōu)化索引問題 4、程序處理速度問題（批量寫數(shù)據(jù)庫問題）Sql/索引優(yōu)化相關知識當且僅當SQL

8、語句包含where子句的時候觸發(fā)針對可選性高的列建索引多表連接注意在被驅(qū)動表連接字段建索引（小結果表驅(qū)動大結果表）復合索引如何生效:前綴性、按可選性高低排列順序、模糊查詢右側列失效不要把索引列套入函數(shù)或表達式、或使用函數(shù)轉換數(shù)據(jù)類型大篇幅的字段搜索一個詞需要建全文檢索索引才有效JOIN 查詢不同類型字段無法使用索引，如果是string類型還必須是相同的字符集如果Mysql Explain你看到以下現(xiàn)象，請優(yōu)化： 1）出現(xiàn)了Using temporary使用到了臨時表，groupby/orderby常用到 2）rows過多或者幾乎是全表的記錄數(shù)全表掃描 3）key 是 (NULL)無索引 4）p

9、ossible_keys 出現(xiàn)過多待選索引過多減少不必要的排序group by，order by等數(shù)據(jù)類型盡量小而確定：INT、Enum字段盡可能的使用Not Null相同的查詢語句盡量使用變量避免每次都解析帶查詢的增刪改操作會鎖表案例講解：性能測試結果案例講解：存在的問題 分布式系統(tǒng)沒有所有程序同時持續(xù)跑一遍。 Redis緩存的數(shù)據(jù)讀寫正確性沒有詳細驗證。 監(jiān)控平臺加壓時沒有獲取靜態(tài)資源，一個用戶使用一個長連接。（測程序是可以這樣，驗收時不行） 數(shù)據(jù)量沒有加到10萬設備應有的業(yè)務數(shù)據(jù)量。 測試平臺針對程序測試而非驗收時涉及到外部接口的功能應該設置測試樁程序MOCO性能測試誤區(qū) 一提到性能測試

10、就開始打開LR/Badboy錄腳本。 錄完腳本后不對腳本進行分析優(yōu)化就開始加壓。 CPU和內(nèi)存占用率越低越好。 調(diào)整參數(shù)就能優(yōu)化性能。 加機器就能優(yōu)化性能。 內(nèi)存擴容解決性能問題。性能測試工程師需要具備的技能數(shù)據(jù)庫管理和性能優(yōu)化測試工具使用擴展及其原理前端技術和優(yōu)化策略Web、App腳本語言的使用Python、Shell中間件、操作系統(tǒng)基本原理和配置程序語言編程及原理java、c#基本技能有計劃的慢慢啃，木有捷徑可走性能測試工程的幾個階段高級：給出性能優(yōu)化解決方案中級：準確定位性能問題初級：寫腳本程序加壓參數(shù)化一個好的性能測試工程師= 半個DBA + 半個運維 + 半個開發(fā)總結回顧 一個Http請求的執(zhí)行過程4個時間段。 Jm