https://pan.baidu.com/s/1df1HDkFzChYNAbsSazizpw 提取碼：hhn7
jmeter 全系列文檔資料
https://pan.baidu.com/s/1rD3H9EGbu0u11E8ofpAl3A 提取碼：8q65
性能測試初級到高級系列資料
概述
在 jmeter 中，只要提到並發，99% 的同學立馬想到線程組。需要多少並發就啟動多少線程組，這已經成了大部分人的共識。這種理解方式很明顯是把並發數和線程數的概念混淆了。線程組中不光有線程數，也有循環次數。然而大家在負載測試中都主動的忽略了循環的作用。jmeter 中的循環和 lr 中的迭代是一樣的，都是為了模擬出壓力，不要選擇性無視它
實驗
先列出下面兩個需求，大家可以思考一下這兩個需求在 jmeter 里面如何設置場景
需求 1：我有一個頁面，需要測試一下最大支持多少用戶並發？
此時要計算的是最大用戶並發數，強調的是同時操作，也可以理解為同時發起請求
針對需求 1 我們可以通過 RPS 定時器或者階梯加壓線程組測試每秒最大的請求數（壓測實戰分析性能拐點）
需求 2：查詢功能，需要系統能夠在 5 分鍾內能完成 5000 筆查詢業務，同時 90% 的用戶響應時間不超過 3s。最大並發是多少？
此時不強調同時操作，而是強調業務量。也就是說不限制用戶的操作時序，不考慮人的效率。把人當做機器，只要在 5 分鍾內查詢數滿足 5000 筆即可。但是具體有多少用戶才能在 5 分鍾內查詢 5000 次？它是由單次響應時間來決定的。這時就引入了一個經常被人討論的公式：最大並發數=（單次響應時間 * 業務量）/總的業務時間。我的單次響應時間越快，用戶每秒可點擊的次數就越多，那么需求就越容易滿足。
線程數和並發數
針對需求 2，我們如何在 jmeter 中設置場景？由上面的描述可以知道，我們可以計算出最大並發數。那么這個最大並發數對應的就是 jmeter 中的線程數。光有線程數不行，此時又引入了一個迭代的概念。假設單線程下，單次請求的平均響應時間是 200ms，那么這個單線程的請求 1s 內可以迭代 5 次。如果有 100 個線程，那么 1s 內就可以完成 500 筆業務。5 分鍾內完成的業務數就是 5*60*500=15 萬筆。回到我們需求 2，是不是遠遠超綱了？把線程數縮小，其實只需要 4 個線程，就可以在 5 分鍾內超額完成 5000 筆業務了。4*5*5*60=6000
1-1
如圖 1-1，勾選循環永遠的意思就是不限制單位時間內的迭代次數，以此加載最大壓力。
注：如果循環次數設置了固定值，那么下發那個持續時間的設置是無效的。線程組會優先根據你的固定循環次數去執行迭代。也就是說，固定循環次數的執行順序優於持續時間！但是如果循環次數設置為永遠，再設置持續的時間，那么就會根據你的持續時間去加載最大的壓力。
事物完成線程組（TPS 線程組）
針對需求 2，jmeter 額外提供了一個線程組去滿足它-- Arrivals Thread Group。在這個線程組中我們給予預期的業務量和業務時間，系統會自動啟動線程去滿足業務需求。
1-2
如圖 1-2，表示我的預期 tps 是 50/s，在 2s 內達到預期值，同時保持這個 tps 運行 20s，那么 22s 內我的業務量是 22*50=1100
1-3
如圖 1-2，最大的系統並發數（啟動的線程數）是 319
總結
我們做性能測試，壓力都是人為給予系統的。使用工具的目的也是為了模擬出用戶的壓力場景