一、Ultimate Thread Group字段解釋
解釋：
- Start Threads Count：啟動多少線程
- Initial Delay,sec：延遲多少秒開始啟動線程
- Startup Time,sec：啟用{Start Threads Count} 個線程花費多少秒
- Hold Load For,sec：線程全部啟動完成后再持續運行多少秒，在此期間，每個線程請求完一遍后會再次發起相同的請求，若有思考時間，則會間隔設定的思考時間后再發起
- Shutdown Time：在多少秒內將 {Start Threads Count} 個線程全部停掉
二、應用舉例
1、不延遲：
2、延遲6秒開始啟動線程：
3、通過多行設置實現梯度加壓：
三、添加監聽器（Active Threads Over Time）（單位時間內活動的線程數）
線程數與Ramp-Up時間
線程數就是我們設置是虛擬用戶數，可以理解為1個線程，就是一個虛擬用戶。
Ramp-Up時間 也就是啟動時間，或者說是准備時間，比如我們設置線程數為10，那么這些用戶不是一瞬間就來的，它需要有一個准備的時間。
線程數10， Ramp-Up時間設置為1秒，那么在1秒內會啟動這些線程。
線程數10， Ramp-Up時間設置為2秒，那么在2秒內會啟動這些線程。
設置線程數10， Ramp-Up時間設置為1秒
從上面結果看出在1秒內，線程全部啟動完畢
設置線程數10， Ramp-Up時間設置為2秒
四、添加監聽器（Response Times Over Time）（響應時間-隨着時間推移）
RT 也就是平均響應時間(Reponse Time), 在聚合報告里面可以看平均值(單位是毫秒)，如果我們想查看更詳細的報告，跟着每個時間段的平均響應時間。
添加-監聽器-jp@gc - Response Times Over Time
壓測后，先看聚合報告的平均值92毫秒
再看實時監控的平均響應時間
間隔時間:500ms (隔500ms，把這500ms收到的請求的平均響應時間標記紅點顯示在圖表上)
它的紅點是指這個間隔里面請求的平均響應時間
目的：拿請求耗時是為了用excel繪制柱形圖
解決方法：jp@gc - Response Times Distribution
這種曲線圖，在寫性能報告的時候加上會顯示更專業
原文地址https://www.cnblogs.com/yoyoketang/tag/jmeter/,轉載請注明出處！
五、添加監聽器（Response Times vs Threads）（響應時間-隨着線程/用戶增多）
六、添加監聽器（Transactions per Second）（每秒事務數/每秒服務器處理客戶端請求數）
TPS(Transaction Per Second) :每秒事務數，通常指每秒成功的事務數，性能測試中重要的綜合性性能指標，代表着服務器的處理能力。一個事務是一個業務度量單位，有時一個事務會包括多個子操作，為了統計方便，會把着多個子操作記為一個事務。
TPS（Transaction per Second）定義：
tps是Transaction per Second的縮寫，也就是事物數/秒。它是軟件測試結果的測量單位，一個事物是指一個客戶機向服務器發送請求飯后服務器做出反應的過程。
客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用時間和完成的事物數，最終利用這些信息來估計得分。
TPS（Transaction per Second）作用：
反映了系統在同一時間內處理業務的最大能力，這個數據越高，說明處理能力越強，描述（看到系統的TPS隨着時間的變化逐漸變大，而在不到多少分鍾的時候系統
每秒可以處理多少個事物。這里的最高值並不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨着負載增加而逐漸增加，當系統進入繁忙期后，TPS會有所下降。）
TPS（Transaction per Second）局限性：
1、tps是從客戶端角度審視服務器處理能力，並不是說TPS可以達到什么程度就能支持多少並發（例如：一個業務100個交易，另一個業務10個交易）。
2、TPS = 腳本運行期間所有事物總數 / 腳本運行時長，如果使用集合點策略，在腳本執行前的等待時間過程中，服務器沒有處理事務，那么這個時候的TPS和理想中的結果不一致。
3、限制TPS的原因：服務器本身性能、代碼結構、客戶端施加的壓力以及網卡等。
TPS（Transaction per Second）與響應時間的關系：
1、TPS和響應時間在理想狀態下的額定值。如果20個入口，並發數只有10的時候，TPS就是10，而響應時間始終都是1，說明並發不夠，需要增加並發數達到TPS的峰值。
2、如果增加到100並發，則造成了線程等待，引起平均響應時間從 1 秒變成 3 秒，TPS也從20下降到9；TPS和響應時間都是單獨計算出來的，兩者不是互相計算出來的。
3、響應時間和TPS在宏觀上是反比的關系，但是兩者之間沒有直接關系。
TPS（Transaction per Second）在性能測試中的作用：
1、一個系統的吞吐量（承壓能力）與request 對CPU的消耗、外部接口、IO等緊密關聯。單個request對CPU消耗越高，外部系統接口、IO營銷速度越慢，系統吞吐能力越低，反之越高。
2、系統吞吐量幾個重要參數：TPS、並發數、響應時間（TPS = 並發數 / 平均響應時間）
3、利用TPS計算系統最高日吞吐量；
4、找出系統最高TPS和日PV，這兩個要素有相對比較穩定的關系。
5、通過壓力測試或者經營評估，得出最高TPS，然后跟進1的關系，計算出系統最高日吞吐量。例如：B2B中文和淘寶對客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS
和PV關系比例也不一樣。
6、淘寶
A)淘寶的TPS和PV之間關系通常為，最高TPS:PV大約為 1:113600（相當於按最高的TPS訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）B2B中文站
B)B2B的TPS和PV之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1:8個小時左右的關系（09年對offerdateil的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，
可能是因為爬蟲占得比例比較高的原因導致的。
在淘寶環境下，假設我們壓力測試出的TPS為100，那么這個系統的日吞吐量=10011*3600=396萬
這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。
TPS（Transaction per Second）與其他性能指標的關系：
TPS和並發虛擬用戶數（U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：TPS=U_concurrent / (T_response+T_think)。
TPS（Transaction per Second）總結：
1、利用並發用戶數、期望響應時間，可以計算出TPS。
2、TPS只是用來計算的是期望值，性能測試過程中的TPS無法單獨作為性能指標。
3、TPS數據方位理論值贏在10-100之間，低於10和高於100都說明系統存在瓶頸點。
4、利用TPS與平均事物響應時間進行對比，可以分析事物數碼對執行時間的影響。例：當壓力加大，點擊率/tps曲線如果變化緩慢或者有平坦趨勢，很有可能是服務器開始出現瓶頸。
5、TPS是從客戶端角度審視服務器處理能力，不能證明TPS可以達到什么程度就能支持多少並發，兩者沒有必然聯系。
6、TPS會受到負載的影響，也會隨着負載的增加而逐漸增加，當系統進入繁忙期后，TPS會有所下降。
七、添加監聽器（Hits per Second）（每秒點擊數/點擊率）
jp@gc - Hits per Second：每秒點擊量，點擊量在性能測試-常見的性能指標，指的是每秒web服務器接收到的請求數
八、添加監聽器（Response Codes per Second）（測試時間和響應代碼關系圖）
該偵聽器顯示在測試長度內每秒所有樣本的響應代碼速率。在系統經常以錯誤代碼響應或需要區分不同的響應代碼的情況下，此圖非常有用。
九、添加監聽器（Bytes Throughput Over Time）（吞吐量-隨着時間推移）
在壓力測試期間接收和發送的bytes數。
十、添加監聽器（Transaction Throughput vs Threads）（吞吐量-隨着用戶數推移）
每個活動線程數的事務吞吐量，X軸表示的是活動線程數，Y軸表示的是事務吞吐量，F（X,Y）的含義是當系統處於某個活動線程數時，系統當時的事務吞吐量是多少，比如當有10個活動線程時，事務吞吐量是100/s，而當有20個活動線程時，事務吞吐量是50/s，說明隨着用戶訪## 標題問的增加，系統的處理效率開始下降了，從這個圖中可以找到一個臨界點，在多大的活動線程數時，系統達到最大的吞吐量。