《目錄》
-------->認知，了解壓測的一些參數，了解什么是正向的壓測結果
-------->壓測需求一般包含的東西與及步驟
-------->JMeter壓測軟件的介紹，壓測計划中常用模塊的用途
-------->了解怎么給出壓測人員出一份壓測指標，計算自己系統的合理吞吐量
-------->怎么看壓測報告，一份報告都有哪些重點
一、認知
首先明確一點，壓測的目的是為了觀察當前系統的負載能!壓測的結果一般情況可以通過吞吐量與並發數的比例來觀察，吞吐量與並發數呈正相關關系，在一定並發數的情況下，吞吐量越高，說明系統性能越好!
開發的原因需要對吞吐量（TPS）、QPS、並發數、響應時間（RT）幾個概念做下了解：
1. 響應時間(RT)
響應時間是指系統對請求作出響應的時間。直觀上看，這個指標與人對軟件性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。由於一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。當然，往往也需要對每個或每組功能討論其平均響應時間和最大響應時間。
對於單機的沒有並發操作的應用系統而言，人們普遍認為響應時間是一個合理且准確的性能指標。需要指出的是，響應時間的絕對值並不能直接反映軟件的性能的高低，軟件性能的高低實際上取決於用戶對該響應時間的接受程度。對於一個游戲軟件來說，響應時間小於100毫秒應該是不錯的，響應時間在1秒左右可能屬於勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對於編譯系統來說，完整編譯一個較大規模軟件的源代碼可能需要幾十分鍾甚至更長時間，但這些響應時間對於用戶來說都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系統在單位時間內處理請求的數量。對於無並發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。前面已經說過，對於單用戶的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對於並發系統，通常需要用吞吐量作為性能指標。
對於一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常並不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由於每個請求的處理過程中有許多不走難以並發執行，這導致在具體的一個時間點，所占資源往往並不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間並不隨用戶數的增加而線性增加。實際上，不同系統的平均響應時間隨用戶數增加而增長的速度也不大相同，這也是采用吞吐量來度量並發系統的性能的主要原因。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。
3. 並發用戶數
並發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量。與吞吐量相比，並發用戶數是一個更直觀但也更籠統的性能指標。實際上，並發用戶數是一個非常不准確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。一網站系統為例，假設用戶只有注冊后才能使用，但注冊用戶並不是每時每刻都在使用該網站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網站時會花很多時間閱讀網站上的信息，因而具體一個時刻只有部分在線用戶同時向系統發出請求。這樣，對於網站系統我們會有三個關於用戶數的統計數字：注冊用戶數、在線用戶數和同時發請求用戶數。由於注冊用戶可能長時間不登陸網站，使用注冊用戶數作為性能指標會造成很大的誤差。而在線用戶數和同事發請求用戶數都可以作為性能指標。相比而言，以在線用戶作為性能指標更直觀些，而以同時發請求用戶數作為性能指標更准確些。
4. QPS每秒查詢率(Query Per Second)
每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。 （類似於TPS，只是應用於特定場景的吞吐量）
二、如何做一個壓測需求?
步驟1：壓力測試分兩種場景：
一種是單場景只壓一個接口的；第二種是混合場景，多個有關聯的接口。
壓測時間，一般場景都運行10-15分鍾。如果是疲勞測試，可以壓一天或一周，根據實際情況來定。
步驟2：壓測前要明確壓測功能和壓測指標，一般需要確定的幾個問題：
固定接口參數進行壓測還是進行接口參數隨機化壓測？
要求支持多少並發數？單接口多少，關聯接口多少
TPS（每秒鍾處理事務數）目標多少？響應時間要達到多少？
被壓的服務器名稱或者被壓的服務器IP，一般都是壓測指定的服務器
步驟3：進行壓測(詳細見下面應用分析)
步驟4：壓測分析與調整
有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的范圍內；
Throughput吞吐量每秒請求的數大於並發數，則可以慢慢的往上面增加；若在壓測的機器性能很好的情況下，出現吞吐量小於並發數(線程數)，說明並發數不能再增加了，可以慢慢的往下減，找到最佳的並發數；
壓測結束，·登陸相應的web服務器查看CPU等性能指標，進行數據的分析;
最大的tps:不斷的增加並發數，加到tps達到一定值開始出現下降，那么那個值就是最大的tps。
最大的並發數：最大的並發數和最大的tps是不同的概率，一般不斷增加並發數，達到一個值后，服務器出現請求超時，則可認為該值為最大的並發數。
壓測過程出現性能瓶頸，若壓力機任務管理器查看到的cpu、網絡和cpu都正常，未達到90%以上，則可以說明服務器有問題，壓力機沒有問題。
影響性能考慮點包括：數據庫(重點)、應用程序、中間件（tomact、Nginx）、網絡和操作系統等方面。
步驟5：出壓測--->聚合報告
本次壓測的要求指標，性能要求
本次壓測的機器性能
本次壓測的各項各項指標
本次壓測的報告結果分析
壓測報告建議
壓測報告等級
三、介紹及入門
JMiter壓測軟件：一款通過不斷提高對系統壓力，用於測試系統性能，如負載，功能，性能，回歸等；的有簡潔明了的圖形界面軟件!
JMeter原理：向服務器提交請求並從服務器取回請求返回的結果
一般有如下一整個流程:
在JMeter中，一個完整的測試計划將包括一個或多個元素，如線程組，邏輯控制器，樣品產生控制器，監聽器，定時器，斷言和配置元素。測試計划必須至少有一個線程組。一般分五個步驟:（1）添加線程組 （2）添加http請求 （3）在http請求中寫入接入url、路徑、請求方式和參數 （4）添加查看結果樹 （5）調用接口、查看返回值。其作用和各自的功能如下：
1、 測試計划：測試的起點，其他配置原件的容器
2、線程組：代表一定數量的並發用戶，它可以用來模擬並發用戶發送請求
3、取樣器Spamler：代表了各種各樣的請求
4、監聽器：負責收集測試結果，同時也被告知了結果顯示的方式。功能是對取樣器的請求結果顯示、統計一些數據（吞吐量、KB/S……）等
5、斷言：用於來判斷請求響應的結果是否如用戶所期望，是否正確。它可以用來隔離問題域，即在確保功能
正確的前提下執行壓力測試。這個限制對於有效的測試是非常有用的。
6、定時器：負責定義請求（線程）之間的延遲間隔，模擬對服務器的連續請求。
7、邏輯控制器：允許自定義JMeter發送請求的行為邏輯，它與Sampler結合使用可以模擬復雜的請求序列。
8、配置元件維護Sampler需要的配置信息，並根據實際的需要會修改請求的內容。
9、前置處理器和后置處理器負責在生成請求之前和之后完成工作。前置處理器常常用來修改請求的設置，后置處理器則常常用來處理響應的數據。
三、應用與分析
1. 看性能分報告，一般一個JMeter有如下參數可以參考
2. 接口指標
5.聚合報告怎么看?
行業經驗：對於游戲行業而言，對於性能的要求是非常高的，響應和延遲是其中最為重要的指標。其性能底線往往是要求90%用戶的響應時間是在1秒內，對於2-3秒的用戶響應只有一些非常小點擊率的請求時才會適當允許! 對於一般的商業系統，性能不錯的在1~2秒作用，3~5秒則稍微難以接受。這個性能指標是指90%的用戶響應秒數。
TPS：吞吐量——默認情況下表示每秒完成的請求數（Request per Second)，當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數! tps越高說明服務器處理能力越好
Min：最小響應時間
Max：最大響應時間
90%Line ：90%請求的響應時間
Average ：每個請求的平均響應時間
Median ：中值，即50%請求的平均響應時間
Samples ：各個測試的樣本總數 ，也即是說線程數*循環次數，
Error%：本次測試中出現錯誤的請求的數量/請求的總數
KB/Sec：每秒從服務器端接收到的數據量，相當於LoadRunner中的Throughput/Sec
QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准
注意：如果初步設計壓測的聚合報告，對很多參數不甚明了，那么可以重點關注TPS，MIN與MAX，Error%，以及90%Line這幾個參數。它可以讓你初步得到如下結論：
當並發在多少（線程數）的時候，每秒的TPS是多少，每秒的查詢率QPS是多少QPS；當前系統90%Line用戶的響應時間是多少，最長的響應時間是多少Max，最快的響應時間是多少MIN。壓測中出現多少錯誤率Error，與目標允許的容錯率xxxx 不符合/符合，請開發解決!
————————————————
原文鏈接：https://blog.csdn.net/qq_36505948/article/details/82425110