【效能調優】效能測試、分析與調優基礎

效能測試除了為獲取效能指標外，更多是為了發現效能瓶頸和效能問題，然後針對效能問題和效能瓶頸進行分析和調優

效能測試的基礎

效能可以理解為一個系統實現其功能的能力
巨集觀：

• 系統能夠穩定執行
• 高併發訪問時系統不會出現當機
• 系統處理完成使用者請求需要的時間
• 系統能夠同時支撐的併發訪問量
• 系統每秒可以處理完成的事務數

微觀：

• 處理每個事務的資源開銷（包括CPU、磁碟I/O、記憶體、網路傳輸頻寬）
• 服務連線數
• 服務執行緒數
• JVM Heap使用情況
• 記憶體的分配和回收是否及時
• 快取規則的命中率

不同的群體對效能的理解可能存在很大的差異
普通的使用者更關心響應時間和穩定性：

• 訪問頁面響應還讓我等多久才能載入出來？
• 為什麼有時候會訪問失敗？為什麼會出現錯誤502？

架構師和工程師更關心架構設計和程式碼編寫的效能：

• 應用架構設計是否合理？
• 技術架構設計是否合理？
• 資料架構設計是否合理？
• 部署架構設計是否合理？
• 程式碼是否存在效能問題？
• JVM中是否有不合理的記憶體分配和使用？
• 執行緒同步和執行緒鎖是否合理？
• 程式碼的計算演算法是否可以優化CPU的消耗時間？

運維工程師更關注系統的監控和穩定性：

• 伺服器各項資源使用率是否正常範圍內？
• 資料庫的連結數是否在正常範圍內？
• SQL執行時間是否正常，是否存在慢查詢日誌？
• 系統能否支撐7*24小時連續不間斷的業務訪問？
• 系統是否高可用？伺服器節點當機是否會影響使用者使用？
• 節點擴容是否可以提高系統的效能？

常見的效能測試指標

響應時間
請求或者某個操作從發出的時間到收到伺服器響應的時間的差值就是響應時間
請求可能經過的處理路徑和節點，那麼響應時間的計算方式就是所有路徑消耗的時間和每個伺服器節點處理時間的累加，通常是網路時間+應用程式的處理時間

TPS
事務是自定義的某個操作或者一組操作的集合
TPS是Transaction Per Second的縮寫，即系統每秒能夠處理的交易和事務的數量，一般統計的是每秒處理的事務數

併發使用者數
在真實的使用者操作中，使用者的每個相鄰操作之間都會有一定的間隔時間（使用者思考時間）
併發使用者中有絕對併發和相對併發

• 絕對併發：某個時間點同時一起向伺服器發起的請求的併發使用者數
• 相對併發：一段時間內向伺服器發出請求的併發使用者總數

單就效能指標而言，系統的併發使用者數是指系統可以同時承載的正常使用系統功能的使用者總數量

PV/UV

• PV：Page View的簡寫，即頁面的瀏覽量或者點選量
• UV：Unique Visitor的簡寫，即指系統的獨立訪客

點選率
每秒的頁面點選數我們稱為點選率（通常說的hit），該效能指標反映客戶端每秒向服務端提交的請求數
在效能測試中，我們一般不發起靜態請求（指靜態資源的請求，比如JS、CSS、圖片檔案等），所以hit指的是動態請求

不發起靜態請求是因為靜態請求一般是可以走快取，比如CDN等，很多靜態請求一般都不需要經過應用伺服器的處理，要麼直接走CDN快取，要麼直接請求到Web伺服器就被處理完成

吞吐量
吞吐量指系統在單位時間內處理客戶端請求的數量，從不同的角度看，吞吐量的計算方式可以不一樣：

• 從業務角度：吞吐量可以用請求數/s、頁面數/s等來進行衡量計算
• 從網路角度：吞吐量可以用位元組數/s來進行衡量計算
• 從應用角度：吞吐量指標反映的是伺服器成熟的壓力，即系統的負載能力
  一個系統的吞吐量一般與一個請求處理對CPU的消耗、頻寬的消耗、IO和記憶體資源的消耗情況等緊密相連

資源開銷
每個請求或事務對系統資源部的消耗，用來衡量請求或者事務對資源的消耗程度，比如：

• 對CPU的消耗可以用佔用CPU的秒數或者核數來衡量
• 對記憶體的消耗可以用記憶體使用率來衡量
• 對IO的消耗可以用每秒讀寫磁碟的位元組數來衡量

效能測試的目標

一、瞭解系統的各項效能指標
通過效能壓測來了解系統能承受多大的併發訪問量、系統的平均響應時間是多少，系統的TPS是多少

二、發現系統中存在的效能問題

• 系統中是否存在負載均衡不均的情況：

負載均衡不均衡一般指的是在併發的情況下，每臺伺服器接收的併發壓力不均勻，從而導致部分伺服器因為壓力過大而出現效能急劇下降，以及部分伺服器因為併發過小而出現資源浪費的情況

• 系統中是否存在記憶體洩漏的情況：

記憶體洩漏指的是應用程式程式碼在每次執行完後，不會主動釋放記憶體資源而導致記憶體使用一直增加，最終會使伺服器實體記憶體全部耗光
系統中是否存在連線洩漏的問題：
連線洩漏種類非常廣泛，可以是資料庫連線洩漏、HTTP連線洩漏或者其他TCP/UDP連線洩漏等。除了系統實際需要情況建立長連線外，一般短連線都應該是用完就需要關閉和釋放

• 系統中是否存線上程安全的問題：

執行緒安全問題是高併發訪問的多執行緒處理系統中經常出現的問題，如果系統中存線上程安全問題，就會出現多個執行緒先後更改資料，造成所得到的資料全部是髒資料，有時候甚至造成巨大的經濟損失

• 系統中是否存在死鎖的問題：

死鎖問題是多執行緒系統中經常會遇到的一個經典的問題，一般常見的有系統死鎖、資料庫死鎖

• 系統中是否存在網路架構或應用架構擴充套件性問題：

擴充套件性問題一般指的是效能指標無法滿足預期的情況下，通過橫向或者縱向擴充套件硬體資源後，系統效能指標無法按照一定的線性規律進行快速遞增

三、解決效能壓測中存在的問題和性別瓶頸

通過不斷的效能調優，使得系統可以滿足預期的效能指標

效能需求分析

一、明確目標
熟悉被壓測系統的基本業務流程，明確此處效能測試要達到的目標，與多方溝通找到業務需求的效能點
二、熟悉架構
熟悉系統的應用架構、技術架構、資料架構、部署架構等，找到與其他系統的互動流程，明確系統部署的硬體配置資訊、軟體配置資訊，把對效能測試有重要影響的關鍵點明確列舉出來，一般包括：

• 呼叫關係

使用者發起請求的順序，請求之間的相互呼叫關係

• 業務資料流走向

資料是如何流轉的、經過了哪些應用服務、經過了哪些儲存服務

• 評估系統瓶頸

評估被壓測系統可能存在的重點資源消耗，是I/O消耗型、CPU消耗型，還是記憶體消耗型，這樣在壓測時可以重點進行監控

• 關注應用的部署架構

如果是叢集部署，壓測時需要關注應用的負載均衡轉發是否均勻，每臺應用伺服器資源消耗是否大體一致

• 瞭解併發架構

明確併發架構是採用多執行緒處理還是多程式處理，重點需要關注是否會死鎖、資料是否一致、執行緒同步鎖是否合理（鎖的顆粒度不宜過大，過大可能會影響併發執行緒的處理）

三、系統上線的資料

明確系統上線後可能達到的最大併發使用者數、使用者期望的平均響應時間以及峰值時的業務吞吐量，並將這些資訊轉換成效能需求指標

效能測試方案
需要按照效能需求分析的結果來制定效能測試方案，即按照什麼樣的思路和策略去測試、需要設計哪些測試場景以及測試場景執行的先後順序、每個測試場景需要重點關注的效能點等，一般包括：
測試場景的設計
單場景設計：單一業務流程的處理模式設計
混合場景設計：多個業務流程同時混合處理模式的設計

定義事務
測試方案中需要明確定義好壓測