線上業(yè)務壓測的核心要素

做到 5 個一樣
要達成精準衡量業(yè)務承接能力的目標，業(yè)務壓測就需要做到 5 個一樣：

• 一樣的線上環(huán)境
• 一樣的用戶規(guī)模
• 一樣的業(yè)務場景
• 一樣的業(yè)務量級
• 一樣的流量來源

做到 5 個“一樣”，讓系統(tǒng)提前進行“模擬考”，從而達到精準衡量業(yè)務模型實際處理能力的目標，便于相應的性能提升、限流降級方案準備等配套工作。

其實這樣的條件，基本上在中小型公司是難以到達的條件。

總結出業(yè)務壓測的核心要素是：

• 壓測環(huán)境
• 壓測基礎數(shù)據
• 壓測流量（模型、數(shù)據）
• 流量發(fā)起、掌控
• 問題定位

那么，壓測流量（模型、數(shù)據）是可以通過 線上請求的錄制拉取下來,比如使用Gor錄制線上請求，序列化成Json String， 持久化到redis；流量發(fā)起可以借助于Jmeter或者Gatling、Loadrunner來產生或者也可以使用使用TCPCopy直接放大線上流量（開發(fā)和運維操作）；最后問題定位一般通過監(jiān)控系統(tǒng)觀察錯誤和響應時間或者通過代碼打點統(tǒng)計日志數(shù)據，當然也可以通過自建的ELK日志分析和配合Grafana來監(jiān)控服務器來排查問題，如果需要方便進行端到端的全監(jiān)控和問題排查可以引入APM這樣的系統(tǒng)。

關于壓測環(huán)境和壓測基礎數(shù)據

結合起來一起講：

全新生產環(huán)境。如果是剛遷移到云上或者是新的機房，全鏈路的進行業(yè)務壓力測試之后可以進行正式投產的，這種驗證效果較好，因為最終就是真實的性能環(huán)境，一般可以將真實的生產環(huán)境數(shù)據進行脫敏導入，確保業(yè)務數(shù)據量（交易數(shù)據、流水、各種業(yè)務核心業(yè)務記錄等）維持在半年以上，同時確保數(shù)據的關聯(lián)完整性（包括跨系統(tǒng)的業(yè)務完整性數(shù)據），壓測基于這些基礎數(shù)據進行相應的核心業(yè)務的流量（登陸、購物車行為、交易行為等）構建，最后在投產前做相應的數(shù)據清理再初始化一次存量基礎數(shù)據。

等比性能環(huán)境。一般是指在生產環(huán)境單獨劃分區(qū)域，準備等比的容量，共享接入層的性能測試環(huán)境。這種方案缺點是成本較高，優(yōu)點是方案簡單、風險可控，容量規(guī)劃較為精準。其中需要注意的幾個點是，1必須保證有共享的接入層（CDN動態(tài)加速、BGP、WAF、SLB、4層7層負載均衡等等，確保最重要的網絡接入層相同，能發(fā)現(xiàn)問題）；2是后端的服務容量配比上至少保證是生產環(huán)境的1/4，配比越大精準度也會大幅下降，數(shù)據庫建議能相同配置。最后，在基礎數(shù)據的準備上和上面全新生產環(huán)境的方法一致。

生產環(huán)境。生產環(huán)境上基礎數(shù)據基本分為兩種方式，一種是數(shù)據庫層面不需要做改造，直接基于基礎表里的測試賬戶（相關的數(shù)據完整性也要具備）進行，壓測之后將相關的測試產生的流水數(shù)據清除（清除的方式可以固化sql腳本或者落在系統(tǒng)上）；另一種就是壓測流量單獨打標（如單獨定義的Header），然后業(yè)務處理過程中識別這個標并傳遞下去，包括異步消息和中間件，最終落到數(shù)據庫的影子表或者影子庫中，一般稱之為全鏈路壓測。此外，生產環(huán)境的壓測盡量在業(yè)務低峰期進行從而避免影響生產的業(yè)務，無論上述哪種方式都可以通過部署單獨的壓測專用集群來進一步避免對生產業(yè)務的影響。

關于業(yè)務的擋板

一般生產環(huán)境的業(yè)務壓測還會涉及到和第三方的交互，如短信、支付和渠道對接等等，往往需要mock掉。最后，關于方案的選擇應該結合實際的情況如人力資源、機器資源、時間成本、業(yè)務復雜度、業(yè)務要求和后續(xù)的維護成本綜合考慮最適合自身的方案。

理想的性能測試方案, 至少滿足如下幾個場景

• 可持續(xù)集成，也就是固定的服務在部署到特定的環(huán)境后可以自動使用老的數(shù)據回歸性能。
• 監(jiān)控平臺化，可以隨時調出待測服務器集群中的某臺設備查看TPS/QPS和CPU 句柄數(shù) 連接數(shù) 流量 JVM的profile數(shù)據 數(shù)據庫的狀態(tài)數(shù)據 。
• 應用自身log統(tǒng)計數(shù)據的對應關系圖，可以隨時調出上個季度的服務器性能和當前的服務器性能做對比。
• 問題定位方便，可隨時根據時間點和曲線圖的拐點分析特定時間段的各類指標和應用log

性能測試方法的核心

根據不同的測試目的，性能測試可以分為多種類型，常見的有如下幾類：

• 基準測試（Standard Testing）
• 負載測試（Load Testing）
• 壓力測試（Stress Testing）
• 疲勞強度測試

首先說下基準測試?；鶞蕼y試指的是模擬單個用戶執(zhí)行業(yè)務場景時，考察系統(tǒng)的性能指標。嚴格意義上來講，基準測試并不能算作性能測試范疇，它跟功能測試并沒有太大區(qū)別。差異在于，基準測試的目的更多地是關注業(yè)務功能的正確性，或者說驗證測試腳本的正確性，然后，將基準測試時采集得到的系統(tǒng)性能指標，作為基準測試結果，為后續(xù)并發(fā)壓力測試的性能分析提供參考依據。

負載測試，主要指的是模擬系統(tǒng)在正常負載壓力場景下，考察系統(tǒng)的性能指標。這里說的正常負載，主要是指用戶對系統(tǒng)能承受的最大業(yè)務負載量的期望值，即預計系統(tǒng)最大應該支持多大用戶的并發(fā)量。通過負載測試，目的是驗證系統(tǒng)是否能滿足預期的業(yè)務壓力場景。

和負載測試的概念比較接近的是壓力測試。通俗地講，壓力測試是為了發(fā)現(xiàn)在多大并發(fā)壓力下系統(tǒng)的性能會變得不可接受，或者出現(xiàn)性能拐點（崩潰）的情況。在加壓策略上，壓力測試會對被測系統(tǒng)逐步加壓，在加壓的過程中考察系統(tǒng)性能指標的走勢情況，最終找出系統(tǒng)在出現(xiàn)性能拐點時的并發(fā)用戶數(shù)，也就是系統(tǒng)支持的最大并發(fā)用戶數(shù)。

最后再說下疲勞強度測試。其實疲勞強度測試的加壓策略跟負載測試也很接近，都是對系統(tǒng)模擬出系統(tǒng)能承受的最大業(yè)務負載量，差異在于，疲勞強度測試更關注系統(tǒng)在長時間運行情況下系統(tǒng)性能指標的變化情況，例如，系統(tǒng)在運行一段時間后，是否會出現(xiàn)事務處理失敗、響應時間增長、業(yè)務吞吐量降低、CPU/內存資源增長等問題。

通過對比可以發(fā)現(xiàn)，不同的性能測試類型，其本質的差異還是在加壓策略上，而采用何種加壓策略，就取決于我們實際的測試目的，即期望通過性能測試發(fā)現(xiàn)什么問題。明白了這一點，性能測試類型的差異也就不再容易混淆了。

結論要點1：性能測試手段的重點在于加壓的方式和策略。

性能瓶頸定位的核心

在前面頻繁地提到了性能指標，那性能指標究竟有哪些，我們在性能測試的過程中需要重點關注哪些指標項呢？

從維度上劃分，性能指標主要分為兩大類，分別是業(yè)務性能指標和系統(tǒng)資源性能指標。

業(yè)務性能指標可以直觀地反映被測系統(tǒng)的實際性能狀況，常用的指標項有：

• 并發(fā)用戶數(shù)
• 事務吞吐率（TPS/RPS）
• 事務平均響應時間
• 事務成功率

而系統(tǒng)資源性能指標，主要是反映整個系統(tǒng)環(huán)境的硬件資源使用情況，常用的指標包括：

• 服務器：CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數(shù)、磁盤IO狀態(tài)、網卡帶寬使用情況等；
• 數(shù)據庫：數(shù)據庫連接數(shù)、數(shù)據庫讀寫響應時長、數(shù)據庫讀寫吞吐量等；
• 網絡：網絡吞吐量、網絡帶寬、網絡緩沖池大小；
• 緩存（Redis）：靜態(tài)資源緩存命中率、動態(tài)數(shù)據緩存命中率、緩存吞吐量等；
• 測試設備（壓力發(fā)生器）：CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數(shù)、磁盤IO狀態(tài)、網卡帶寬使用情況等。

對于以上指標的具體含義我就不在此進行逐一說明了，大家可以自行搜索，務必需要搞清楚每個指標的概念及其意義?？赡苡行┲笜嗽诓煌牟僮飨到y(tǒng)中的名稱有些差異，但是基本都會有對應的指標，其代表的意義也是相通的。例如，處理器隊列長度這個指標，在Windows中的指標名稱是System\Processor Queue Length，而在Linux系統(tǒng)中則需要看load averages。

TPS模式（吞吐量模式）是一種更好的方式衡量服務端系統(tǒng)的能力。

TPS獲取新系統(tǒng)：沒有歷史數(shù)據作參考，只能通過業(yè)務部門進行評估。舊系統(tǒng)：對于已經上線的系統(tǒng)，可以選取高峰時刻，在5分鐘或10分鐘內，獲取系統(tǒng)每筆交易的業(yè)務量和總業(yè)務量，按照單位時間內完成的筆數(shù)計算出TPS，即業(yè)務筆數(shù)/單位時間（560或1060）

系統(tǒng)的性能由TPS決定，跟并發(fā)用戶數(shù)沒有多大關系。
系統(tǒng)的最大TPS是一定的（在一個范圍內），但并發(fā)用戶數(shù)不一定，可以調整。

可能對于最后一項（測試設備）有些人不大理解，監(jiān)控被測系統(tǒng)環(huán)境的相關硬件資源使用情況不就好了么，為什么還要關注測試設備本身呢？這是因為測試設備在模擬高并發(fā)請求的過程中，設備本身也會存在較高的資源消耗，例如CPU、內存、網卡帶寬吃滿，磁盤IO讀寫頻繁，處理器排隊嚴重等；當出現(xiàn)這類情況后，測試設備本身就會出現(xiàn)瓶頸，無法產生預期的并發(fā)壓力，從而我們測試得到的數(shù)據也就不具有可參考性了。此處暫不進行展開，后面我會再結合實際案例，通過圖表和數(shù)據對此詳細進行說明。

需要說明的是，性能指標之間通常都是有密切關聯(lián)的，單純地看某個指標往往很難定位出性能瓶頸，這需要我們對各項性能指標的含義了然于胸，然后才能在實際測試的過程中對系統(tǒng)性能狀況綜合進行分析，找出整個系統(tǒng)真正的瓶頸。舉個簡單的例子，壓力測試時發(fā)現(xiàn)服務器端CPU利用率非常高，那這個能說明什么問題呢？是服務端應用程序的算法問題，還是服務器硬件資源配置跟不上呢？光看這一個指標并不能定位出產生問題的真正原因，而如果僅因為這一點，就決定直接去優(yōu)化程序算法或者升級服務器配置，最后也很難真正地解決問題。

結論要點2：性能瓶頸定位的重點在于性能指標的監(jiān)控和分析。

壓測場景的結構和數(shù)據分配

基本概念

• 壓測 API：指由用戶行為觸發(fā)的一條端上請求，是壓測中的必需元素。

• 串聯(lián)鏈路：指一組壓測 API 的有序集合（類似于事務），具有業(yè)務含義。

• 數(shù)據導出指令：用于導出某個串聯(lián)鏈路中的數(shù)據（導出 Cookie 為典型應用），供其他串聯(lián)鏈路使用，實現(xiàn)導出數(shù)據的全局共享。

• 關聯(lián)數(shù)據文件：壓測 API使用了來自數(shù)據文件的參數(shù)，從而關聯(lián)了相應的數(shù)據文件。如果使用了多個文件參數(shù)分別來自于不同數(shù)據文件則表示關聯(lián)了多個數(shù)據文件。

• 斷言：一般用于標記業(yè)務成功與否，從而驗證壓測請求的響應是否符合預期。

• 數(shù)據輪詢一次：在請求中使用文件參數(shù)時，數(shù)據文件只輪詢一次，以保證請求信息不重復。

• 出參：在創(chuàng)建串聯(lián)鏈路時，將前置接口的部分返回信息作為參數(shù)。

依賴登錄的壓測場景結構
下圖中串聯(lián)鏈路1 的 API1 是登錄業(yè)務相關接口，其典型配置如下圖：

image.png

圖例說明如下：

• 數(shù)據導出指令一般應用于登錄之后需要并行壓測多個不同業(yè)務串聯(lián)鏈路的情況，支持標準的 Cookie 導出或者是業(yè)務自定義的 出參 導出。

• 串聯(lián)鏈路1 使用了數(shù)據導出指令，數(shù)據導出完成后其他串聯(lián)鏈路才能開始壓測，所以與其他串聯(lián)鏈路不是并行的關系。
  說明：只有當使用了數(shù)據導出指令才會出現(xiàn)串聯(lián)鏈路之間不是全都并行的情況。

• 為保證用戶登錄信息不重復，需設置壓測 API 數(shù)據只輪詢一次。串聯(lián)鏈路1 中 API1 設置了數(shù)據只輪詢一次。

• 一批用戶登錄完成后，將用戶登錄信息共享給場景內其他業(yè)務的串聯(lián)鏈路使用，需設置數(shù)據導出的準備量級。達到該量級才會觸發(fā)場景內剩余串聯(lián)鏈路進行壓測（它們彼此間還是并行的，數(shù)據分配邏輯和上面所述一致）。

• 準備量級需要小于等于登錄接口的文件行數(shù)。如圖所示，關聯(lián)數(shù)據文件為 200 行，導出量級設置為 100。

注意：由于目前任務是拆分給施壓agent單獨執(zhí)行的，故可能出現(xiàn)準備量級并沒有達到設定值便有其他串聯(lián)鏈路開始壓測的情況。

引入性能測試工具

通過前面的講解，我們已經知道性能測試的主要手段是通過產生模擬真實業(yè)務的壓力對被測系統(tǒng)進行加壓，與此同時監(jiān)控被測系統(tǒng)的各項性能指標，研究被測系統(tǒng)在不同壓力情況下的表現(xiàn)，找出其潛在的性能瓶頸。

那么，如何對系統(tǒng)進行加壓，又如何對系統(tǒng)的指標進行監(jiān)控呢？這里，就需要引入性能測試工具了。

當然，我們也可以先看下在不借助性能測試工具的情況下，如何手工地對系統(tǒng)進行性能測試。

假設現(xiàn)在我們要對前面提到的搜索功能進行負載測試，驗證在20個并發(fā)用戶下搜索功能的事務平均響應時間是否在3秒以內。

很自然地，我們可以想到測試的必要條件有如下幾點：

• 20個測試人員，產生業(yè)務壓力
• 1個指揮人員，對20個人員的協(xié)調控制，實現(xiàn)并發(fā)操作
• 1個結果記錄人員，對每一個人員的操作耗時進行監(jiān)控和記錄
• 若干資源監(jiān)控人員，實時查看被測系統(tǒng)的各項性能指標，對指標進行匯總、分析
• 1個結果統(tǒng)計人員，對20個用戶各操作消耗的時長進行匯總，計算其平均值

可以看出，要通過人工來進行性能測試，操作上極為繁瑣，需要投入的資源非常多，而這還僅僅是一個非常簡單的場景。設想，如果要測試10000并發(fā)，服務器有好幾十臺，顯然，這種情況下是完全不可能通過投入人力就能解決的。這也就是性能測試工具存在的必要性和誕生的背景。

性能測試工具的基本組成

當前，市面上已經有了很多性能測試工具，但不管是哪一款，基本都會包含如下幾個核心的模塊。

• 壓力生成器（Virtual User Generator）
• 結果采集器（Result Collector）
• 負載控制器（Controller）
• 系統(tǒng)資源監(jiān)控器（Monitor）
• 結果分析器（Analysis）

原理結構圖如下所示：

Google Search

對照前面手工進行性能測試的案例，不難理解，壓力發(fā)生器對應的是眾多測試人員，結果采集器對應的是結果記錄人員，負載控制器對應的是指揮人員，資源監(jiān)控器對應的是若干資源監(jiān)控人員，結果分析器對應的是結果統(tǒng)計人員。

其中，壓力發(fā)生器又是性能測試工具最核心的部分，它主要有兩個功能，一是真實模擬用戶操作，二是模擬有效并發(fā)。

然而，大多數(shù)性能測試工作人員可能都會忽略的是，當前市面上性能測試工具的壓力發(fā)生器基本都是存在缺陷的。

先說下模擬真實用戶操作。如果熟悉瀏覽器的工作原理，就會知道瀏覽器在加載網頁的時候，是同時并發(fā)多個TCP連接去請求頁面對應的HTTP資源，包括HTML、JS、圖片、CSS，當前流行的瀏覽器普遍會并發(fā)6-10個連接。然而，性能測試工具在模擬單個用戶操作的時候，基本上都是單連接串行加載頁面資源。產生的差異在于，假如頁面有100個資源，每個HTTP請求的響應時間約為100毫秒，那么瀏覽器采用6個連接并行加載網頁時大概會需要1.7秒（100/6*100毫秒），而測試工具采用單連接串行加載就需要10秒（100*100毫秒），兩者結果相差十分巨大。這也解釋了為什么有時候我們通過性能測試工具測試得到的響應時間挺長，但是手動用瀏覽器加載網頁時感覺挺快的原因。

再說下有效并發(fā)。什么叫有效并發(fā)？有效并發(fā)就是我們在測試工具中設置了1000虛擬用戶數(shù)，實際在服務器端就能產生1000并發(fā)壓力。然而現(xiàn)實情況是，很多時候由于測試設備自身出現(xiàn)了性能瓶頸，壓力發(fā)生器產生的并發(fā)壓力遠小于設定值，并且通常測試工具也不會將該問題暴露給測試人員；如果測試人員忽略了這個問題，以為測試得到的結果就是在設定并發(fā)壓力下的結果，那么最終分析得出的結論也就跟實際情況大相徑庭了。不過，我們可以通過保障測試環(huán)境不存在瓶頸，使得實際生成的并發(fā)壓力盡可能地與設定值一致；另一方面，我們也可以通過在測試過程中監(jiān)控Web層（例如Nginx）的連接數(shù)和請求數(shù)，查看實際達到服務器端的并發(fā)數(shù)是否跟我們的設定值一致，以此來反推壓力發(fā)生器的壓力是否有效。

了解這些缺陷的意義在于，我們可以更清楚測試工具的原理，從而更準確地理解測試結果的真實含義。

性能測試工具推薦

經過充分的理論鋪墊，現(xiàn)在總算可以進入正題，開始講解工具部分了。

在性能測試工具方面，我重點向大家推薦Locust這款開源工具。目前階段，該款工具在國內的知名度還很低，大多數(shù)測試人員可能之前都沒有接觸過。為了便于理解，我先將Locust與LoadRunner、Jmeter這類大眾耳熟能詳?shù)男阅軠y試工具進行簡單對比。

授權方式這個就不說了。雖然LoadRunner是商業(yè)軟件，價格極其昂貴，但是國內盜版橫行，別說個人，就算是大型互聯(lián)網公司，用正版的也沒幾個。

從功能特性的角度來講，LoadRunner是最全面的，用戶群體也是最多的，相應的學習資料也最為豐富。個人建議如果是新接觸性能測試，可以先熟悉LoadRunner，借此了解性能測試工具各個模塊的概念和功能，在此基礎上再轉到別的測試工具，也都比較好上手了。不過，LoadRunner只能在Windows平臺使用，并且并發(fā)效率比較低，單臺壓力機難以產生較高的并發(fā)能力，并且不符合現(xiàn)在DevOps的理念，現(xiàn)在大部分互聯(lián)網企業(yè)也很少用到這樣的重型武器了。

同樣地，Jmeter的并發(fā)機制也是基于線程，并發(fā)效率存在同樣的問題；另外，Jmeter在腳本編寫和描述方面是基于GUI操作，也相對簡單，Jmeter是一個輕量級的工具了，依賴于Java，并且社區(qū)也相對活躍，使用Jmeter的企業(yè)也有很多，容易進行二次開發(fā)。

Gatling，這是一款發(fā)布很久但在國內使用范圍不是很廣泛的壓測工具。使用的是和Java同源的Scala這樣的小眾語言開發(fā)的，同時腳本也是基于Scala的。

Locust是一款Python的性能測試框架，非常小巧靈活，使用Python來進行編寫腳本，因為采用協(xié)程模式，單機并發(fā)可以到達比較高，但是缺陷也比較明顯，還沒有形成一個完整的生態(tài)，很多多謝都需要自己進行二次開發(fā)。

采用多線程來模擬多用戶時，線程數(shù)會隨著并發(fā)數(shù)的增加而增加，而線程之間的切換是需要占用資源的，IO的阻塞和線程的sleep會不可避免的導致并發(fā)效率下降；正因如此，LoadRunner和Jmeter這類采用進程和線程的測試工具，都很難在單機上模擬出較高的并發(fā)壓力。而協(xié)程和線程的區(qū)別在于，協(xié)程避免了系統(tǒng)級資源調度，由此大幅提高了性能。正常情況下，單臺普通配置的測試機可以生產數(shù)千并發(fā)壓力，這是LoadRunner和Jmeter都無法實現(xiàn)的。面對這樣的情況可以考慮選擇Locust和Gatling這樣協(xié)程并發(fā)的工具來進而實現(xiàn)目標。

性能測試結果

我認為一個完整的性能測試結果應該有四部分構成，預期目標、測試腳本、測試結果、調優(yōu)建議

預期目標

這個預期目標是我們做性能測試的前提，只有確定了預期目標，獲得了大家的一直認可，以此為基準。
一般預期目標會是，

接口每天被5000個人調用，同時在線500人，每天要被調用50000次，這種話一般都是什么產品說出來的，因為，他們根本不管你什么原理不原理的，反正就是說，我的系統(tǒng)要怎么樣怎么樣，能做到多少支撐量。

或者更加官方點會附帶，我們系統(tǒng)需要的TPS是多少，在完成這樣的TPS中，CPU和內存不能超過多少，在這樣的前提下有支持多少用戶的并發(fā)，這樣聽起來就比前面的好多了。

測試腳本

測試腳本就是，我們?yōu)榱送瓿蛇@個性能測試任務設計的腳本，讓它來模擬線上用戶的真實情況對服務器產生壓力。

這是非常關鍵的一環(huán)，因為設計的腳本好壞，直接關系到最終的測試結果，
常見的設計思路是使用80/20原則來計算平均峰值來作為我們的指標。

80/20峰值公式：80%的業(yè)務是在20%的業(yè)務時間內完成的

image.png

當然28原則也不能硬套，需要使用實際的生產數(shù)據來做出統(tǒng)計，有時候跟28原則差距還是很大的，甚至有可能是1:100
真實的tps需要用底層的qps來計算，而業(yè)務應該承受的并發(fā)需要根據這個基礎結合場景自己去推算.。

測試結果

這里一般就會使用到各種監(jiān)控工具來，持續(xù)觀察服務器的狀態(tài)。

image.png

這個監(jiān)控工具看自己業(yè)務的實際情況而定。

調優(yōu)

確定問題

應用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對于發(fā)現(xiàn)瓶頸的模塊，應該首先檢查一下代碼。數(shù)據庫配置：經常引起整個系統(tǒng)運行緩慢，一些諸如大型數(shù)據庫都是需要DBA進行正確的參數(shù)調整才能投產的。操作系統(tǒng)配置：不合理就可能引起系統(tǒng)瓶頸。硬件設置：硬盤速度、內存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。網絡：網絡負載過重導致網絡沖突和網絡延遲。

分析問題

當確定了問題之后，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？是多數(shù)用戶還是少數(shù)用戶遇到了問題？如果是少數(shù)用戶，這幾個用戶與其它用戶的操作有什么不用？系統(tǒng)資源監(jiān)控的結果是否正常？CPU的使用是否到達極限？I/O 情況如何？問題是否集中在某一類模塊中？ 是客戶端還是服務器出現(xiàn)問題？ 系統(tǒng)硬件配置是否夠用？實際負載是否超過了系統(tǒng)的負載能力？ 是否未對系統(tǒng)進行優(yōu)化？通過這些分析及一些與系統(tǒng)相關的問題，可以對系統(tǒng)瓶頸有更深入的了解，進而分析出真正的原因。

確定調整目標和解決方案

高系統(tǒng)吞吐量，縮短響應時間，更好地支持并發(fā)。

測試解決方案

對通過解決方案調優(yōu)后的系統(tǒng)進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統(tǒng)，實現(xiàn)對一類測試對象的某項性能指標進行定量的和可對比的測試）。

分析調優(yōu)結果

系統(tǒng)調優(yōu)是否達到或者超出了預定目標？系統(tǒng)是整體性能得到了改善，還是以系統(tǒng)某部分性能來解決其他問題。調優(yōu)是否可以結束了。最后，如果達到了預期目標，調優(yōu)工作可以先告一段落。

調優(yōu)注意事項

• 在應用系統(tǒng)的設計開發(fā)過程中，應始終把性能放在考慮的范圍內，將性能測試常態(tài)化，日?；膬染W的性能測試+定期的真實環(huán)境的業(yè)務性能測試。
• 確定清晰明確的性能目標是關鍵。
• 必須保證調優(yōu)后的程序運行正確。
• 系統(tǒng)的性能更大程度上取決于良好的設計，調優(yōu)技巧只是一個輔助手段。
• 調優(yōu)過程是迭代漸進的過程，每一次調優(yōu)的結果都要反饋到后續(xù)的代碼開發(fā)中去。
• 性能調優(yōu)不能以犧牲代碼的可讀性和可維護性為代價