性能調優常規手段（理論）

性能調優常規手段

性能調優就是用更少的資源提供更好的服務，成本利益最大化。性能調優的手段並不新鮮，性能調優常規手段有：

(1)   空間換時間，內存、緩存就是典型的空間換時間的例子。利用內存緩存從磁盤上取出的數據，CPU請求數據直接從內存中獲取，從而獲取比從磁盤讀取數據更高的效率。

(2)     時間換空間，當空間成爲瓶頸時，切分數據分批次處理，用更少的空間完成任務處理。上傳大附件時常常用這種方式。

(3)     分而治之，把任務切分，分開執行，也方便並行執行來提升效率。

(4)     異步處理，業務鏈路上有任務時間消耗較長，能夠拆分業務，減小阻塞影響。常見的異步處理機制有MQ（消息隊列），目前在互聯網應用中大量使用。

(5)     並行，多個進程或者線程同時處理業務，縮短業務處理時間，好比咱們在銀行辦理業務時，若是排隊人數較多時，銀行會加開櫃檯。

(6)     離用戶更近一點，好比CDN技術，把用戶請求的靜態資源放在離用戶更近的地方。

(7)     一切可擴展，業務模塊化、服務化（同時無狀態化）、良好的水平擴展能力。

 

分佈式架構的運用給性能帶來了革命性的提高，業務流程的調整也會顯著提高系統性能，單系統的調優可以壓榨出更高的處理能力。單機性能分析調優可從從如下四部分入手：

(1)     性能分析方法

(2)     基於單機的性能分析與調優

(3)     基於業務流程優化的性能分析調優

(4)     基於結構（分佈式、業務拆分）的性能分析與調優

 

性能分析方法

性能分析是一個大課題，不一樣的架構、不一樣的應用場景、不一樣的程序語言分析的方法如有差別，抽象一下大體分爲兩類。

(1)     自底向上：經過監控硬件及操做系統的指標（CPU、內存、磁盤、網絡等硬件資源的性能指標）來分析性能問題（配置、程序等問題）。由於用戶請求最終是由計算機硬件設備來完成的，作事的是CPU。

(2)     自頂向下：經過生成負載來觀察被測試的系統性能，好比響應時間、吞吐量；而後從請求的起點由外及裏一層一層的分析，從而找到性能問題所在。

不論是自上而下仍是自下而上，關鍵點就是生成負載、監控性能指標。好一點的方式是先用自頂向下的方式解決掉明顯的性能問題，再結合自底向上的方式分析更深層次的問題。

 

單機的性能分析與調優

常見的J2EE應用架構，通常分爲Web層（請求接入、負載均衡、頁面渲染等）、應用層（業務邏輯實現）、持久化曾（數據記錄）。

         下面列出了性能測試時咱們須要關注的指標。

 

 

 

Client：客戶瀏覽器，好比IE、Chrome等訪問Web頁面。

Load Machine：是生成負載的機器，即咱們的壓測機器用來模擬用戶負載。

Web Server：提供Web服務的服務器，即咱們訪問的Web頁面由此服務器提供服務；通常都部署在Nginx、Apache等中間件上。

Middleware：中間件，好比Tomcat、Jboss、WebLogic等。

OS：操做系統，Windows或者Linux。

System Resource：系統資源，好比CPU、內存、磁盤、網絡等。

App Server：應用服務，實現業務邏輯，好比生成訂單，生成統計報表。

DB：數據庫服務器，好比Oracle、Mysql、SqlServer等。

（1）

RT：響應時間，一筆業務的完成時間。

TPS：每秒完成的事物數。

CPU：CPU的性能指標，好比CPU利用率、CPU負載。

Mem：內存性能指標，好比可用物理內存、虛擬內存使用率。

Disks：Disk性能指標， 好比Disk Time、IO等待。

Network：網絡指標，如帶寬使用率，任務隊列長度。

         （2）

         TCP Connections：指TCP鏈接數，能夠用netstat命令統計獲得。

         Thread Pool：中間件創建的線程池，監控線程狀態。

         JVM：JVM性能指標，好比GC狀況，Heap使用狀況。

         Load Average：CPU負載隊列長度。

         （3）

         DB Connections：中間件與數據庫之間創建的鏈接數及鏈接狀態。

（4）

         DB Time：消耗在數據庫操做上的CPU時間。

         TOP SQL：按內存佔用由多到少排序SQL，按CPU佔用由多到少排序SQL。

         PGA、SGA：PGA、SGA內存使用狀況。

性能分析過程：

序號	步驟名稱	說明
1	檢查RT	模擬用戶發起負載後，採用的自頂向下的方式首先分析RT（響應時間）
2	檢查TPS	TPS大時RT小，說明性能良好
3	檢查負載機資源	檢查CPU使用率，CPU負載（Load Average）確認是用戶CPU佔用高仍是系統CPU佔用高 前提：確認測試腳本沒有性能問題，不會形成結果統計的不許確 檢查內存使用狀況，確認併發內存泄漏風險，不會形成結果統計的不許確
4	判斷負載機是否有性能問題	排除負載機的性能問題，確保測試結果可參考
5	檢查Web服務器的資源消耗	（1）檢查CPU使用率，確認用戶CPU與系統CPU佔用狀況 （2）檢查內存使用狀況 （3）檢查磁盤使用狀況 （4）檢查佔用的帶寬 （5）分析Web頁面響應的時間組成，確認是什麼請求影響了性能
6	確認是否Web服務器瓶頸	標判斷是不是Web服務器硬件性能瓶頸
7	檢查中間件配置	確認是不是此配置問題
8	檢查APP服務器資源消耗	關注CPU、內存、磁盤、IO，判斷是不是App服務器硬件性能瓶頸
9	數據庫服務器資源消耗分析	（1）CPU消耗，CPU負載 （2）內存消耗 （3）IO繁忙程度 （4）數據庫監控
10	是不是DB性能問題	由監控結果來判斷是不是DB性能問題
11	是否SQL問題	（1）定位最不合理的SQL佔比 （2）索引是否正常引用 （3）檢查共享SQL是否合理範圍 （4）檢查解析是否合理 （5）檢查數據ER結構是否合理 （6）檢查數據熱點問題 （7）檢查數據分佈是否合理 （8）檢查碎片整理等
12	其餘	好比網絡阻塞、磁盤IO瓶頸、熱點等

上表列舉了一種典型的分析思路，能夠看到性能測試結果分析是一個考驗綜合知識的活動，涉及了多方面的知識，包括但不限於下面7部分：

（1）       硬件知識（CPU、RAM、Disk、Net等）。

（2）       系統知識（OS----Linux、Windows）。

（3）       中間件知識（JVM、Tomcat、Jboss、WebLogic、WebSphere等）。

（4）       數據庫知識（Mysql、Sql Server、Oracle、DB二、Sysbase等）。

（5）       網絡知識（好比截包分析）。

（6）       程序知識，好比Java程序，如何讓程序更高效。

（7）       架構知識，好比SSH架構。

大型系統的複雜度已經不是一我的力所能及的事情。上面提到的7個部分就能夠是多個崗位（運維、程序員、架構師、DBA等），每一個崗位又配置專業人員。性能分析時從他們那裏獲取性能指標數據，這些信息彙總後用來判斷是否有性能問題。

對於性能測試工程師來講首先要作到的事情是要知道監控哪些指標？這些指標反應什麼問題？何時去關注這些監控信息？在性能測試執行與分析時你就是總設計師，負責協調這些事項。

 

程序優化

程序調優是治本的手段，當前性能測試每每都是在SIT測試完成後進行的，性能問題暴露得太晚，這個時候去修改代碼，風險較大。因此性能測試每每要提早規劃，先架構後程序（先總體後個體）。

（1）       系統框架選擇

SSH架構是當下最流行的MVC模型。SSH架構提供了明晰的層次結構，各層協同完成業務實現，簡化了程序設計過程，加快了程序交付進程。可是對大型的業務系統，特別是大數據量的分析計算過程，能夠把數據處理換成在數據庫中進行處理，減小網絡傳輸，性能也會提高，因此應該不一樣的應用場景選擇更合適的處理方式。

（2）       程序優化

低效代碼優化，排除架構問題，純粹是程序邏輯及算法抵消，好比邏輯混亂、調用繼承不合理、內存泄漏等。常見的解決方法以下：

1. 表單壓縮，減小網絡的傳輸量
2. 局部刷新，減小向服務器的請求
3. 僅取所需，只向服務器請求必要的內容
4. 邏輯清晰，方便維護、方便分析問題；不作錯誤及多餘的調用，資源請求後可以釋放
5. 謹慎繼承，開發過程對系統架構熟悉，合理調用，減小大對象產生的可能
6. 程序算法優化，提升查詢程序效率
7. 批處理，對於大數據最好作成分批處理
8. 延遲加載，對於大對象的展現能夠採用延遲加載，好比分頁，用到分頁時再去請求
9. 防止內存泄漏
10. 減小大對象的引用
11. 防止爭用死鎖
12. 索引：編寫合理的SQL，儘可能利用索引
13. 內存分配，合理分配數據庫內存，好比PGA與SGA的設置
14. 並行，使用多進程或進程來處理任務
15. 異步，好比用MQ來解耦系統之間的依賴關係，減小阻塞
16. 使用好的設計模式來優化程序，好比用回調來減小阻塞，使用監聽器來阻塞依賴
17. 選擇合適的IO模式，好比NIO、AIO等

（3）       配置優化

1. JVM配置優化：合理的分配堆與非堆的內存，配置適合的內存回收算法，提升系統服務能力
2. 鏈接池：數據庫鏈接池能夠節省創建鏈接與關閉鏈接的資源消耗
3. 線程池：經過緩存線程的狀態來減小新建線程與關閉線程的開銷，通常是在中間件中進行配置，好比在Tomcat的server.xml文件中進行配置
4. 緩存機制：經過數據的緩存來減小磁盤的讀寫壓力，縮小存儲與CPU的效率差

（4）       數據庫鏈接池優化

數據庫鏈接池存在的意義是讓鏈接複用，經過創建一個數據庫鏈接池（緩衝區）以及一套鏈接使用、分配、管理策略，使用的該鏈接池中的鏈接能夠獲得高效、安全的複用，避免了數據庫鏈接頻繁創建、關閉的開銷。

鏈接池的主要關注的問題：

1. 鏈接池的配置參數。
2. 鏈接池配置多少鏈接合適
3. 監控鏈接池

（5）       線程優化

1. 線程池優化，線程池是爲了減小建立新線程和銷燬線程的系統資源消耗
2. CPU處理能力
3. 內存容量
4. 系統線程數限制

（6）       DB優化

一般使用數據庫有3個要求，性能好、數據一致性有保障、數據安全可靠；數據庫優化前提也是這3個要求。

1. 優化物理結構，數據庫邏輯設計與物理設計要科學高效，好比分區、索引創建、字段類型及長短、冗餘設計等
2. 共享SQL、綁定變量、下降高水位
3. 查詢器優化，特殊狀況調整執行計劃。指定的執行計劃加快查找速度。好比鏈接查詢時指定驅動表，減小表的掃描次數
4. 單條SQL優化，對單條SQL進行優化分析，好比查詢條件選擇索引列
5. 並行SQL，對數據量巨大的表的數據遍歷，用多個線程分塊處理任務。
6. 減小資源爭用（鎖、閂鎖、緩存），能夠提升IO效率減少響應時間從而提升吞吐量來緩解爭用，好比用緩存；能夠物理拆分把熱點數據分佈在不一樣表空間

（7）       優化內存、減小物理IO訪問

（8）       優化IO，進行條帶化、讀寫分離、減小熱點等

注意：單系統性能分析的思路是經過現象結合監控鎖定性能問題（程序、配置、IO等）

單系統性能調優的思路是減小資源佔用，減小請求

 

業務流程優化

         準確地說就是業務架構調整，業務架構是整個系統好壞成敗的關鍵，對此處作調整就是推翻先前的設計，風險比較大。這點對於架構師的要求很明確。現實每每是殘酷的，反過來想一下，正是由於這種矛盾的存在才致使了性能測試以及性能調優的存在。

        

結構優化

業務的增加致使性能問題推進着架構的發展，從單機到集羣再到分佈式結構。