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