當一個應用系統需求被提出，就需要確定性能需求，即：需要給多少人同時來使用，就是多少人可以同時在線；平均響應時間有多長；每秒通過的交易（transaction）個數有多少；需要的網絡帶寬有多大等等。
系統設計，就需要遵循性能需求，進行性能架構設計。比如，是否使用集群、雙機熱備、N+1等模式。當然，隨著兩地三中心的模式，也需要充分考慮到性能需求和性能架構設計的要求。
決定性能的要素，包括了：性能需求、性能架構與設計、代碼實現幾個部分。
性能架構，很多系統都是分成不同的層，以及不同的業務組件來實現具體的應用，一般而言包括了交易處理層、業務組件層、數據庫服務層三個大的部分。當系統的性能出現問題，我們就需要知道，
上圖是一個比較簡單的架構。當系統的性能達不到要求，我們就要分析問題出在哪一層上。分析在哪一層，最簡單的方法，就是分析業務流量路徑圖：
根據業務流量的路徑，對每個層進行性能數據監控，得到每個模塊被調用的次數，以及響應時間的數據，從而分析獲得性能瓶頸。
隨著業務的復雜度提升，系統架構也日益復雜，出現了微服務或者很多跨系統的業務場景：
如上圖，就需要對外系統或者調用外系統的接口服務進行監控，獲得監控數據。
獲得監控數據之后，就需要對可疑的數據進行分析。什么是可疑的數據？就是按照正常的情況，不應該出現的性能曲線，比如數據庫sql語句執行突然緩慢（隨著數據量的增加），交易響應時間突然變長，但是cpu卻沒有大幅度增加等等。
如上圖，是TPS隨時間變化的趨勢圖。隨著時間的變化，客戶端發起的壓力逐步上升，當上升到一等幅度之后，突然開始震動和下降，出現了性能瓶頸。
最后，我們來說一下加壓。加壓就是模仿客戶端，生成持續的交易請求，向系統加壓。
如上圖，我們采用PerformanceRunne性能測試工具r的架構圖，來展示如何產生壓力：
PR的節點管理器，負責管理多個虛擬機或者實體機，在實體機上會通過多進程和多線程來模擬用戶請求。
模擬用戶請求的方式是采用測試腳本來模擬發起報文和接收響應報文：
簡單的協議，比如http、https、socket等，可以通過錄制來獲得測試腳本，對于復雜的協議或者通訊中間件，比如MQ、tuxedo、cics等，就無法通過錄制來獲得，就需要手工編寫測試腳本。
腳本編寫完成，我們需要對腳本進行參數化，以實現加壓的時候，產生壓力的數據是不同的，從而模擬更真實的應用場景：
針對具體的統計口徑和業務相關性，例如：當我們通過瀏覽器頁面登錄到一個系統，一般而言，登錄是一個服務，登錄完成之后，會請求用戶桌面上的各個數據，或者儀表盤信息，是另外的請求。在產生壓力和統計的時候，我們需要把這兩個或者多個，組合在一起，變成一個交易（transaction），tps的數據也是統計交易的數據，這樣避免了編寫的測試腳本和真實的壓力效果不同，如下圖：
性能測試腳本創建完成，我們就可以根據具體的業務場景來加壓了。一個業務場景，可以對應一個或者多個測試腳本。
壓力產生策略。我們可以選擇逐步梯度增加并發個數（VU虛擬用戶），來逐步產生壓力，發現加壓到某個壓力的時候，會出現性能瓶頸。
性能測試工具，對各個節點進行監控，產生性能監控數據：
推薦閱讀：
sales@spasvo.com
