1. 程式人生 > >軟體效能測試分析與調優實踐之路-效能分析調優思想與調優技術總結

軟體效能測試分析與調優實踐之路-效能分析調優思想與調優技術總結

本文主要闡述軟體效能測試中的一些調優思想和技術,節選自作者新書《軟體效能測試分析與調優實踐之路》部分章節歸納。

一、  效能分析與調優思想

1、效能分析調優模型

效能測試除了為獲取效能指標外,更多是為了發現效能瓶頸和效能問題,然後對效能問題和瓶頸進行分析和調優,在當今網際網路高速發展的時代,效能調優的模型可以歸納總結如下圖所示。

 

 

系統模型中相關的元件描述如下表所示

元件

描述

網路分發

網路分發是高速發展的網際網路時代常用的降低網路擁塞,快速響應使用者請求的一種技術手段,最常用的網路分發就是CDN(Content Delivery Network,即內容分發網路),依靠部署在世界各地的邊緣伺服器,通過中心平臺的負載均衡、源伺服器內容分發、排程等功能模組,使世界各地使用者就近獲取所需內容,而不用每次都到中心平臺的源伺服器獲取響應結果,比如南京的使用者直接訪問部署在南京的邊緣伺服器,而不需要訪問部署在遙遠的北方的北京的伺服器

Web伺服器

Web伺服器用於部署Web服務,Web伺服器的作用就是負責請求的響應和分發以及靜態資源的處理

Web服務

Web服務指執行在Web伺服器上的服務程式,最常見的Web服務就是Nginx和Apache

Web Cache

Web Cache指Web層的快取,一般都是臨時快取HTML、CSS、影象等靜態資原始檔

應用伺服器

應用伺服器用於部署應用程式,如Tomcat、WildFly、普通的Java應用程式(如jar包服務),IIS等

應用程式服務

應用程式服務指執行在應用伺服器上的程式,比如Java應用,C/C++應用、Python應用,一般用於處理使用者的動態請求

應用快取

應用快取指應用程式層的快取服務,常用的應用快取技術有Redis、Memcached等,這些技術手段也是動態擴充套件的高併發分散式應用架構中經常使用的技術手段

資料庫(DB)

用於資料的儲存,可以包括關係型資料庫以及NoSql資料庫(非關係型資料庫),常見的關係型資料庫有Mysql、Oracle、Sqlserver、DB2等,常見的NoSql資料庫有Hbase、MongoDB、ElasticSearch等

外部系統

指當前系統依賴於其他的外部系統,需要從其他的外部系統中通過二次請求獲取資料,外部系統有時候可能會存在很多個

上圖中的系統模型是一個網際網路中常見的使用者請求的分層轉發和處理的過程,在效能調優時就是不斷採集系統中的效能指標以及系統模型中各層的資源消耗,從中發現效能瓶頸和效能問題,然後對瓶頸和問題進行分析診斷來確定性能調優方案,最後通過效能壓測進行驗證調優方案是否有效,如果無效繼續重複這個過程進行效能分析,直到調優方案有效,瓶頸和問題得到解決。這個過程一般是非常漫長,因為很多時候效能調優方案往往不是一次就能有效或者一次就能解決所有的瓶頸和問題,或者解決了當前的瓶頸和問題,但是繼續效能壓測又可能會出現新的瓶頸和問題。

轉載請註明出處:來源於部落格園,作者:張永清,https://www.cnblogs.com/laoqing/p/13660768.html

2、效能分析與調優思想

2.1、分層分析

分層分析指的就是按照系統模型以及系統架構分層按照呼叫鏈進行監控分析和問題排查,如下圖所示。

 

 

  •          分層排查一般需要對系統的應用架構層次以及部署架構非常的熟悉,需要熟悉請求的處理鏈過程。
  •          分層排查一般需要對每一層建立checklist,然後按照每層的checklist逐一進行分析。
  •          分層排排查效率較低,但是往往能發現更多的效能問題。
  •          分層排查可以自上而下也可以自下而上。

2.2、科學論證

科學論證一般包括髮現問題、問題假設、預測、試驗論證、分析這5個步驟,如下圖所示。

 

 

  •          發現問題:指通過效能採集和監控,發現了效能瓶頸或者效能問題,比如併發使用者數增大後TPS並不增加、每臺應用伺服器的CPU消耗相差特別大等。
  •          問題假設:指根據自己的經驗判斷,假設是某個因素導致了出現瓶頸和問題。
  •          預測:指根據問題假設,預測可能出現的一些現象或者特徵。
  •          試驗論證:根據預測,去檢查預期可能出現的現象或者特徵
  •          分析:根據獲取到的實際現象或者特徵進行分析,判斷假設是否正確,如果不正確,就重新按照這個流程進行分析論證。

科學論證法進行效能分析與調優的示例如下圖所示。

 

 

2.3、問題追溯與歸納總結

(1)、問題追溯分析指的是根據問題去追溯最近系統或者環境發生的變化,一般適用於生產已上線系統的版本釋出或者環境變動導致的效能問題,問題追溯的步驟一般如下圖所示,問題追溯分析是通過在追溯和描述中去逐步排查可能導致問題的原因。

 

 

(2)、歸納總結指的根據經驗的總結,在出現某種效能瓶頸或者效能問題時根據以往總結的原因進行逐一排查。

 

二、  效能調優技術

1、快取調優

網際網路高速發展的這個時代,快取使用已經成為了很多大型系統或者電商網站使用的一個關鍵技術,合理的設計快取直接關係到了一個系統或者網站的併發訪問能力和使用者體驗。網站按照存放地點的不同可以分為使用者端快取和服務端快取,如下圖所示。

 

 

 

快取調優的關鍵點說明如下:

  •          如何讓快取的命中率更高?
  •          如何注意防止快取穿透?
  •          如何控制好快取的失效時間?
  •          如何做好快取的監控分析?比如slow log分析、連線數監控、記憶體使用監控。
  •          如何防止快取雪崩?快取雪崩指的是伺服器在出現斷電等極端異常情況後,快取中的資料全部丟失,導致大量的請求全部需要從資料庫中直接獲取資料從而資料庫壓力過大造成資料庫崩潰,防止快取雪崩需要注意:

(1)       要處理好快取資料全部丟失後,如何能快速把資料重新載入到快取中。

(2)       快取資料的分散式冗餘備份,當出現數據丟失時,可以迅速切換使用備份資料。

2、同步轉非同步推送

 同步:指的是系統收到一個請求後,在該請求沒有處理完成時,就一直不返回響應結果,直到處理完成了才返回響應結果,如下圖所示。

轉載請註明出處:來源於部落格園,作者:張永清,https://www.cnblogs.com/laoqing/p/13660768.html

 

 

非同步:與同步相比,非同步指的是系統收到一個請求後,隻立即返回請求呼叫方請求接收成功,在請求處理完成後,再非同步推送處理結果給呼叫方,或者請求呼叫方在間隔一定時間再重新來獲取請求結果。如下圖所示。

 

 轉載請註明出處:來源於部落格園,作者:張永清,https://www.cnblogs.com/laoqing/p/13660768.html

同步轉非同步主要是解決同步請求時的阻塞等待,一直處於阻塞等待的請求,往往會造成連線不能快速釋放,從而導致高併發處理時,連線數不夠用,通過佇列非同步接收請求後,請求處理方再進行分散式的並行處理,從而達到處理能力擴充套件,並且網路連線也可以快速釋放。

3、拆分

拆分指的是將系統中的複雜的業務呼叫拆分為多個簡單的呼叫,如下圖所示,一般遵循的原則如下:

  •          對於高併發的業務請求呼叫都單獨拆分為單個的子系統應用。
  •          對於併發訪問量接近的業務,可以按照產品業務進行拆分,相同的產品業務都歸類到一個新的子系統中。

 

 

系統拆分帶來的好處就是高併發的業務不會對低併發業務的效能造成影響,而且系統在硬體擴充套件時,也可以有針對性的進行擴充套件,避免資源的浪費。

4、任務分解與平行計算

任務分解與平行計算指的是將一個任務拆分為多個子任務,然後將多個子任務並行進行計算處理,最後只需要再將平行計算的結果合併在一起返回即可。目的是通過平行計算的方式來增加處理效能,如圖所示。

 

 轉載請註明出處:來源於部落格園,作者:張永清,https://www.cnblogs.com/laoqing/p/13660768.html

另外對於包含多個處理步驟的序列任務,也可以儘量按照如下圖所示的方式轉換為平行計算處理。

 

 5、索引與分庫分表

索引指應用程式在查詢時,儘量走資料庫索引查詢,資料庫表在建立時也儘量對查詢條件的欄位建立合適的索引,這裡強調一定是合適的索引,如果索引建立不合適,不僅對查詢效率沒有任何的幫助,反而會使資料庫表在插入資料時變的更慢,因為一旦建立了索引後,資料在插入時,索引也會自動更新,這樣就加大資料庫的插入時的資源消耗。比如資料庫表中有一個欄位為“status”,而“status”的取值只有0、1、2 三個值,這時候如果對“status”建立索引,對查詢效率就沒有任何幫助,因為“status”欄位的值只有1、2、3這三個值,建立索引後根據“status”去檢索時,需要掃描的資料還是非常的大,因為“status”欄位的取值範圍太少,過濾出來的資料量還是非常的龐大。

正確的使用索引可以很好的提高查詢效率,但是如果一個表的資料量非常的龐大,比如達到了億萬級別了,此時索引查詢很慢了,並且新資料插入時也很慢,此時就需要對資料進行分表或者分庫了,分庫一般指的是一個數據庫的儲存已經很大了,查詢和插入時I/O消耗非常大,此時就需要將資料庫拆分成2個庫來減輕讀寫時I/O的壓力,如下圖所示。

 

 轉載請註明出處:來源於部落格園,作者:張永清,https://www.cnblogs.com/laoqing/p/13660768.html

常見的分庫分表方式如下:

  •          按照冷熱資料分離的方式:一般將使用頻率非常高的資料稱之為熱資料,查詢頻率較低或者幾乎不被查詢的資料稱之為冷資料,冷熱資料分離後,熱資料單獨儲存,這樣資料量就會下降下來了,查詢的效能自然也就提升了,而且還可以更方便的單獨針對熱資料做I/O的效能調優了。
  •          按照時間維度的方式:比如可以按照實時資料和歷史資料分庫分表,也可以按照年份、月份等事件區間進行分庫分表,目的是儘可能的減少庫表中的資料量。
  •          按照一定的演算法計算的方式:此種方式一般適用於資料都是熱資料的情況,比如資料無法做冷熱分離,所有的資料都經常被查詢,而且資料量又非常的大。此時就可以根據資料中的某個欄位做演算法計算(注意的是這個欄位一般是資料查詢時的檢索條件欄位),使得資料能均勻的落到不同的分表中去,查詢時再根據查詢條件欄位做演算法計算就可以快速的定位到是需要到哪個表中去進行查詢。

資料分庫分表後,帶來的另一個好處就是,如果單次查詢時,需要查詢多個分表,那麼此時就可以通過多執行緒並行的方式去查詢每個分表,最後對每個分表的查詢結果做一次合併即可,這樣也可以使得查詢的效率更高。

關於軟體效能分析調優,可以加微訊號yq597365581或者微訊號hqh345932,進入專業的效能分析調優群進行交流溝通。

 

 

備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。

本文作者:張永清  文章選自 作者2020年初即將出版的《軟體效能測試、分析與調優實踐之路》一書。文章連結:https://www.cnblogs.com/laoqing/p/13660768.html

  

 

個人介紹:從事功能測試、自動化測試、效能測試、Java軟體開發、大資料開發、架構師等工作十多年,在自動化測試設計、效能測試設計、效能診斷、效能調優、分散式架構設計等方面積累了多年經驗,參與過的系統涉及公安、網際網路、移動網際網路、大資料、人工智慧等領域。先後任職於江蘇飛搏軟體、蘇寧大資料研發中心、蘇寧研究院、蘇寧人工智慧研發中心、紫金普惠研發中心等公司,歷任測試經理、技術經理、部門經理、高階架構師等職位,重點關注大資料、影象處理、高效能分散式架構設計等領域,著有《robot framework 自動化測試框架核心指南》、《軟體效能測試、分析與調優實踐之路》,apache dolphinscheduler 貢獻者。<