性能調優就是用更少的資源提供更好的服務，成本利益最大化。性能調優的手段並不新鮮，性能調優常規手段有：
- 空間換時間：內存、緩存就是典型的空間換時間的例子。利用內存緩存從磁盤上取出的數據，CPU請求數據直接從內存中獲取，從而獲取比從磁盤讀取數據更高的效率。
- 時間換空間：當空間成為瓶頸時，切分數據分批次處理，用更少的空間完成任務處理。上傳大附件時經常用這種方式。
- 分而治之：把任務切分，分開執行，也方便並行執行來提高效率。
- 異步處理：業務鏈路上有任務時間消耗較長，可以拆分業務，減少阻塞影響。常見的異步處理機制有MQ（消息隊列），目前在互聯網應用中大量使用。
- 並行：多個進程或者線程同時處理業務，縮短業務處理時間，比如我們在銀行辦理業務時，如果排隊人數較多時，銀行會加開櫃檯。
- 離用戶更近一點：比如CDN技術，把用戶請求的靜態資源放在離用戶更近的地方。
- 一切可擴展：業務模塊化、服務化（同時無狀態化）、良好的水平擴展能力。
分佈式架構的運用給性能帶來了革命性的提升，業務流程的調整也會顯著提升系統性能，單系統的調優能夠壓榨出更高的處理能力。單機性能分析調優可從從以下四部分入手：
- 性能分析方法
- 基於單機的性能分析與調優
- 基於業務流程優化的性能分析調優
- 基於結構（分佈式、業務拆分）的性能分析與調優
性能分析方法
性能分析是一個大課題，不同的架構、不同的應用場景、不同的程序語言分析的方法若有差異，抽象一下大致分為兩類。
(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等。
RT：響應時間，一筆業務的完成時間。
TPS：每秒完成的事物數。
CPU：CPU的性能指標，比如CPU利用率、CPU負載。
Mem：內存性能指標，比如可用物理內存、虛擬內存使用率。
Disks：Disk性能指標， 比如Disk Time、IO等待。
Network：網絡指標，如帶寬使用率，任務隊列長度。
TCP Connections：指TCP連接數，可以用netstat命令統計得到。
Thread Pool：中間件建立的線程池，監控線程狀態。
JVM：JVM性能指標，比如GC情況，Heap使用情況。
Load Average：CPU負載隊列長度。
DB Connections：中間件與數據庫之間建立的連接數及連接狀態。
DB Time：消耗在數據庫操作上的CPU時間。
OP SQL：按內存佔用由多到少排序SQL，按CPU佔用由多到少排序SQL。PGA、SGA：PGA、SGA內存使用情況。
性能分析過程：
上表列舉了一種典型的分析思路，可以看到性能測試結果分析是一個考驗綜合知識的活動，涉及了多方面的知識，包括但不限於下面7部分：
- 硬件知識（CPU、RAM、Disk、Net等）。
- 系統知識（OS----Linux、Windows）。
- 中間件知識（JVM、Tomcat、Jboss、WebLogic、WebSphere等）。
- 數據庫知識（Mysql、Sql Server、Oracle、DB2、Sysbase等）。
- 網絡知識（比如截包分析）。
- 程序知識，比如Java程序，如何讓程序更高效。
- 架構知識，比如SSH架構。
大型系統的複雜度已經不是一個人力所能及的事情。上面提到的7個部分就可以是多個崗位（運維、程序員、架構師、DBA等），每個崗位又配置專業人員。性能分析時從他們那裡獲取性能指標數據，這些信息彙總後用來判斷是否有性能問題。
對於性能測試工程師來說首先要做到的事情是要知道監控哪些指標？這些指標反應什麼問題？什麼時候去關注這些監控信息？在性能測試執行與分析時你就是總設計師，負責協調這些事項。
程序優化
程序調優是治本的手段，當前性能測試往往都是在SIT測試完成後進行的，性能問題暴露得太晚，這個時候去修改代碼，風險較大。所以性能測試往往要提前規劃，先架構後程序（先整體後個體）。
（1） 系統框架選擇
SSH架構是當下最流行的MVC模型。SSH架構提供了明晰的層次結構，各層協同完成業務實現，簡化了程序設計過程，加快了程序交付進程。但是對大型的業務系統，特別是大數據量的分析計算過程，可以把數據處理換成在數據庫中進行處理，減少網絡傳輸，性能也會提升，所以應該不同的應用場景選擇更合適的處理方式。
（2） 程序優化
低效代碼優化，排除架構問題，純粹是程序邏輯及算法抵消，比如邏輯混亂、調用繼承不合理、內存洩漏等。常見的解決方法如下：
- 表單壓縮，減少網絡的傳輸量
- 局部刷新，減少向服務器的請求
- 僅取所需，只向服務器請求必要的內容
- 邏輯清晰，方便維護、方便分析問題；不做錯誤及多餘的調用，資源請求後能夠釋放
- 謹慎繼承，開發過程對系統架構熟悉，合理調用，減少大對象產生的可能
- 程序算法優化，提高查詢程序效率
- 批處理，對於大數據最好做成分批處理
- 延遲加載，對於大對象的展示可以採用延遲加載，比如分頁，用到分頁時再去請求
- 防止內存洩漏
- 減少大對象的引用
- 防止爭用死鎖
- 索引：編寫合理的SQL，儘量利用索引
- 內存分配，合理分配數據庫內存，比如PGA與SGA的設置
- 並行，使用多進程或進程來處理任務
- 異步，比如用MQ來解耦系統之間的依賴關係，減少阻塞
- 使用好的設計模式來優化程序，比如用回調來減少阻塞，使用監聽器來阻塞依賴
- 選擇合適的IO模式，比如NIO、AIO等
（3） 配置優化
- JVM配置優化：合理的分配堆與非堆的內存，配置適合的內存回收算法，提高系統服務能力
- 連接池：數據庫連接池可以節省建立連接與關閉連接的資源消耗
- 線程池：通過緩存線程的狀態來減少新建線程與關閉線程的開銷，一般是在中間件中進行配置，比如在Tomcat的server.xml文件中進行配置
- 緩存機制：通過數據的緩存來減少磁盤的讀寫壓力，縮小存儲與CPU的效率差
（4） 數據庫連接池優化
數據庫連接池存在的意義是讓連接複用，通過建立一個數據庫連接池（緩衝區）以及一套連接使用、分配、管理策略，使用的該連接池中的連接可以得到高效、安全的複用，避免了數據庫連接頻繁建立、關閉的開銷。
連接池的主要關注的問題：
- 連接池的配置參數。
- 連接池配置多少連接合適
- 監控連接池
（5） 線程優化
- 線程池優化，線程池是為了減少創建新線程和銷燬線程的系統資源消耗
- CPU處理能力
- 內存容量
- 系統線程數限制
（6）DB優化
通常使用數據庫有3個要求，性能好、數據一致性有保障、數據安全可靠；數據庫優化前提也是這3個要求。
- 優化物理結構，數據庫邏輯設計與物理設計要科學高效，比如分區、索引建立、字段類型及長短、冗餘設計等
- 共享SQL、綁定變量、降低高水位
- 查詢器優化，特殊情況調整執行計劃。指定的執行計劃加快查找速度。比如連接查詢時指定驅動表，減少表的掃描次數
- 單條SQL優化，對單條SQL進行優化分析，比如查詢條件選擇索引列
- 並行SQL，對數據量巨大的表的數據遍歷，用多個線程分塊處理任務。
- 減少資源爭用（鎖、閂鎖、緩存），可以提高IO效率減小響應時間從而提高吞吐量來緩解爭用，比如用緩存；可以物理拆分把熱點數據分佈在不同表空間
（7） 優化內存、減少物理IO訪問
（8） 優化IO，進行條帶化、讀寫分離、減少熱點等
注意：單系統性能分析的思路是通過現象結合監控鎖定性能問題（程序、配置、IO等）單系統性能調優的思路是減少資源佔用，減少請求
業務流程優化
準確地說就是業務架構調整，業務架構是整個系統好壞成敗的關鍵，對此處做調整就是推翻先前的設計，風險比較大。這點對於架構師的要求很明確。現實往往是殘酷的，反過來想一下，正是因為這種矛盾的存在才導致了性能測試以及性能調優的存在。
結構優化
業務的增長導致性能問題推動著架構的發展，從單機到集群再到分佈式結構。
閱讀更多 架構師師長 的文章
