性能測試之問題定位分析_第1頁
性能測試之問題定位分析_第2頁
性能測試之問題定位分析_第3頁
性能測試之問題定位分析_第4頁
性能測試之問題定位分析_第5頁
已閱讀5頁,還剩19頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

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

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

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

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

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

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

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

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

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

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論