Jmeter：性能測試指南（轉）

http://yukinami.github.io/2015/11/26/%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95%E6%8C%87%E5%8D%97/

 

性能測試指南

概念

 

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。

• 負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，經過不斷加載（如逐漸增長模擬用戶的數量）或其它加載方式來觀察不一樣負載下系統的響應時間和數據吞吐量、系統佔用的資源（如CPU、內存）等，以檢驗系統的行爲和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。負載測試更多地體現了一種方法或一種技術。
• 壓力測試是在強負載（大數據量、大量併發用戶等）下的測試，查看應用系統在峯值使用狀況下操做行爲，從而有效地發現系統的某項功能隱患、系統是否具備良好的容錯能力和可恢復能力。壓力測試分爲高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載狀況下致使系統崩潰的破壞性壓力測試。

關鍵指標

性能測試監控指標主要分爲：資源指標和系統指標，資源指標與硬件資源消耗直接相關，而系統指標則與用戶場景及需求直接相關

系統性能

重要參數

• 併發數 系統同時處理的請求數/事務數
• 系統吞吐量（Throughput） 吞吐量是指系統在單位時間內處理請求的數量，度量單位是reqeust/s
• 系統延遲（Latency）系統延遲是指系統在處理一個請求或一個任務時的延遲。系統延遲和響應時間的意思大體是一致的。

通常來講，一個系統的性能受到這兩個條件的約束，缺一不可。好比，個人系統能夠頂得住一百萬的併發，可是系統的延遲是2分鐘以上，那麼，這個一百萬的負載毫無心義。系統延遲很短，可是吞吐量很低，一樣沒有意義。因此，一個好的系統的性能測試必然受到這兩個條件的同時做用。

下面的兩個概念對比系統吞吐量是更爲針對性的定義，雖然和吞吐量的計量單位不一樣，但基本是成正比的

• TPS Transactions Per Second 即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。
• QPS Queries Per Second

每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，做爲域名系統服務器的機器的性能常常用每秒查詢率來衡量。

它們之間的關係，Throughput(TPS/QPS) = 併發數/平均響應時間

NOTE: 負載測試的目的就是找出這個Throughput(TPS/QPS)的最大值

系統吞吐量評估

找出系統吞吐量的極限後，咱們須要估算咱們實際對系統吞吐量的需求值，看前者是否可以知足後者。

PV到TPS的轉換

日PV對於一個網站，很容易就統計出來。 日PV和TPS之間如何對應？公式就是80%的日PV，發生在T小時內。則公式爲：

1	TPS = 日PV * 80% / 24 * 60 * 60 * (T/24)

性能測試工具Jmeter

原理

Jmeter工具和其餘性能工具在原理上徹底一致，工具包含4個部分：

• 負載發生器 用於產生負載，一般以多線程或是多進程的方式模擬用戶行爲
• 用戶運行器 一般是一個腳本運行引擎，用戶運行器附加在線程或進程上，根據腳本要求模擬指定的用戶行爲
• 資源生成器 用於生成測試過程當中服務器、負載機的資源數據
• 報表生成器 根據測試中霍地的數據生成報表，提供可視化的數據顯示方式

測試計劃元件

• 測試計劃(Test Plan) 用來描述一個性能測試，包含與本次性能測試全部相關的功能。也就說本的性能測試的全部內容是於基於一個計劃的。
• Threads(Users) 這個就是咱們一般添加運行的線程。通俗的講一個線程組,，能夠看作一個虛擬用戶組，線程組中的每一個線程均可以理解爲一個虛擬用戶。線程組中包含的線程數量在測試執行過程當中是不會發生改變的。
• 取樣器(Sampler) 取樣器(Sample)是性能測試中向服務器發送請求，記錄響應信息，記錄響應時間的最小單元，JMeter 原生支持多種不一樣的sampler ，如 HTTP Request Sampler 、 FTP Request Sample 、TCP Request Sample 、JDBC Request Sampler 等，每一種不一樣類型的 sampler 能夠根據設置的參數向服務器發出不一樣類型的請求
• 邏輯控制器(Logic Controller) 邏輯控制器，包括兩類無件，一類是用於控制test plan 中 sampler 節點發送請求的邏輯順序的控制器，經常使用的有 若是(If)控制器 、switch Controller 、Runtime Controller、循環控制器等。另外一類是用來組織可控制 sampler 來節點的，如 事務控制器、吞吐量控制器。
• 配置元件(Config Element) 配置元件(config element)用於提供對靜態數據配置的支持。CSV Data Set config 能夠將本地數據文件造成數據池(Data Pool)，而對應於HTTP Request Sampler和 TCP Request Sampler等類型的配製無件則能夠修改Sampler的默認數據。(例如，HTTP Cookie Manager 能夠用於對 HTTP Request Sampler 的cookie 進行管理)
• 定時器(Timer) 定時器(Timer)用於操做之間設置等待時間，等待時間是性能測試中經常使用的控制客戶端QPS的手端。相似於LoadRunner裏面的「思考時間」。JMeter 定義了Bean Shell Timer、Constant Throughput Timer、固定定時器等不一樣類型的Timer。
• 前置處理器(Per Processors) 用於在實際的請求發出以前對即將發出的請求進行特殊處理。例如，HTTP URL重寫修復符則能夠實現URL重寫，當RUL中有sessionID 一類的session信息時，能夠經過該處理器填充發出請求的實際的sessionID 。
• 後置處理器(Post Processors) 用於對Sampler 發出請求後獲得的服務器響應進行處理。通常用來提取響應中的特定數據(相似LoadRunner測試工具中的關聯概念)。例如，XPath Extractor 則能夠用於提取響應數據中經過給定XPath 值得到的數據。
• 斷言(Assertions) 斷言用於檢查測試中獲得的相應數據等是否符合預期，斷言通常用來設置檢查點，用以保證性能測試過程當中的數據交互是否與預期一致。
• 監聽器(Listener) 這個監聽器可不是用來監聽系統資源的元件。它是用來對測試結果數據進行處理和可視化展現的一系列元件。 圖行結果、查看結果樹、聚合報告。都是咱們常常用到的元件。

對於Jmeter這些組件能夠這樣理解。 配置測試計劃就是經過代碼來實現對服務器的訪問，代碼除了提供了語法級別的循環遍歷，條件判斷等等，還提供了各類函數庫來供咱們使用。Jmeter的這些組件其實就是實現了一些語法功能以及包括了各類功能的函數，不一樣的組件類型對函數的不能功能進行了分組。 另外除了函數，還提供了一些配置文件來控制這些函數的行爲，這類組件(Config Element)一般做爲子組件配置配置。

後臺服務器性能測試實例

臺服務器性能測試是經過工具和腳本模出真實用戶的請求，經過併發的方式來放大流量測試後臺服務器的性能，並記錄測試結果數據。因此如何獲取和經過工具模擬出單個用戶的行爲是一個必須首先完成的工做。

獲取用戶操做對應的接口請求

經過Charles、fiddler等抓包工具，分析用戶的一個行爲具體有哪些接口請求

模擬用戶請求

接下來須要在性能測試工具中模擬模擬出這樣的請求。基於棘突的協議類型和工具提供的用法，常見的有兩種方式，一是在工具中配置請求，二是經過代碼的方法。Jmeter主要是第一種方法，對於HTTP請求能夠直接配置各類參數，同時Jmeter還提供了錄製的功能。

Jmeter腳本的錄製須要使用HTTP(S) Test Script Recorder，它屬於非測試邏輯單元，添加須要在工做臺才能進行。

Test Script Recorder

Target Controller 指的是做爲腳本錄製結果的Contorller保存到哪，能夠直接保存到測試計劃下，也能夠保存到HTTP(S) Test Script Recorder下。我的建議先臨時保存到HTTP(S) Test Script Recorder下，從新修改組織後，再將最終的Contorlller移動的測試計劃下。

Content-type filter和URL Patterns to Include均可以用來過濾須要錄製的請求，去除一些不關心的內容。這裏須要的是若是請求域名沒有指定端口，那麼URL Pattern裏也須要明確指定80端口，不然沒法正確過濾。

Think Time

若是直接執行錄製下來的腳本有一個很大的問題。在於真實用戶和腳本的不一樣。腳本若是是基於前面的方法錄製的，兩個請求的執行時間之間是沒有任何的其餘的停頓的，其間隔只是依賴於上一個服務的響應時間和測試機發起請求所需的時間。可是顯然真實的用戶不是機器，他們在作上面每個步驟的時候都有一個思考的時間，這也是Think Time這個詞的意義來源。

Think Time在Jmeter能夠通Constant Timer來實現。

Think Time

構建虛擬用戶組

上面介紹的獲取和模擬的是單個用戶的行爲，經過工具放大後其實表明了行爲一致的一類用戶。可是對於個真實的被測系統，一般有不少種使用方式，並非每一個用戶作的步驟都同樣，若是想看系統總體的性能，那就須要同時模擬多類不一樣的用戶，這裏咱們稱之爲虛擬用戶組。

在Jmeter中虛擬用戶組經過，線程組來實現。不一樣的線程組定義不一樣的用戶行爲。