線程組編輯區如下：
有點復雜，但是慢慢看下來，還是比較容易理解。
Name
帶有業務含義的名字。
Comments
線程組的備注說明。
Action to be taken after a Sampler error
取樣器報錯后執行動作。有5個選項：Continue，Start Next Thread Loop，Stop Thread，Stop Test，Stop Test Now。為了搞懂這幾個選項，我畫了張時序圖進行說明：
- 圖中有一個線程，在最左邊。
- 右邊有兩個迭代：迭代1和迭代2。
- 每個迭代有兩個請求，第一個請求失敗。
- Stop Thread是直接結束線程，沒有畫出來，一般不會設置此項，不然會導致運行線程越來越少，最后負載不夠，對服務器的壓力不夠，測試結果不具參考性。
- 剩余4個選項用紅色字體標注了出來。
線程在第一個迭代的第一個請求失敗了。Continue表示繼續執行第二個請求，再執行第二個迭代；Start Next Thread Loop表示忽略第二個請求，跳到第二個迭代執行；Stop Test表示把當前迭代的第二個請求執行完后，停止測試；Stop Test Now表示從第一個請求失敗這里直接結束測試。
JMeter默認選項是Continue，保證足夠的並發壓力。我們在大量用戶並發時，服務器偶爾響應錯誤是正常現象，比如服務器由於性能問題500，此時出錯我們正好要記錄下來，作為有性能問題的依據。
如果想減少關聯請求報錯，可以選擇Start Next Thread Loop。
Thread Properties
Number of Threads (users)
線程組的線程數量。
Ramp-up period (seconds)
啟動時間，線程組在多少秒內啟動完所有線程。
比如設置線程數為50，設置啟動時間為10秒，那么每秒就會啟動50 / 10 = 5個線程；如果設置為0秒，則50個線程會立刻啟動；如果設置為100秒，就會每隔100 / 50 = 2秒啟動1個線程。
Ramp-up period如何設置？
以下是5個線程依次從啟動到執行到退出的示意圖：
JMeter線程組產生的並發壓力，實際上是紅色框起來的那部分，在這個時間段才是所有線程在並發着運行。
先從Ramp-up period設置最小和最大來分析這個問題：
- 假設有3000個線程，只迭代1次，如果設置為0秒，那么測試一開始就會產生3000個並發請求，說不定直接把服務器壓崩了，還沒開始就結束了。
- 假設有10個線程，只迭代1次，如果設置為100秒，那么每隔10秒啟動1個線程，很可能前一個線程跑完了，下一個線程還沒啟起來，某一時刻最多只有1個線程在跑，沒有並發壓力。
接着看看該設置成多少？這個答案我找了很多資料，都沒有明確的說法。結合實踐經驗來談的話，既不能太小，也不能太大，可以根據業務場景、硬件配置、系統資源來進行設置。
Loop Count
迭代次數。
- 填寫數字，指定迭代次數。
- 勾選Infinite，無限迭代，一直運行到測試停止或異常崩潰。
Same user on each iteration
每個迭代都用相同的user（線程）。
默認這個選項是勾選的。因為銷毀和創建線程本身就會占用資源，可能會影響性能測試結果。
什么時候去掉勾選呢？比如登錄，加了HTTP Cookie管理器以后，單個線程多次迭代（注意不是多個線程哦）登錄用的都是相同的Cookie。去掉勾選后，同時在HTTP Cookie管理器選擇清除舊Cookie：
那么每次迭代就能用不同Cookie了。
Delay Thread creation until needed
保持默認就好。跟JVM創建線程時機有關，實際運用勾不勾選都不影響測試結果。
Specify Thread lifetime
Duration
持續時間，單位秒。
前面的Loop Count勾選了Infinite，Duration才會生效。
Startup delay
啟動延遲，單位秒。
延遲到多少秒后再啟動線程。
小結
本文對線程組編輯區進行了揭秘，看似復雜，實則簡單，問題在於實際使用過程中如何結合業務來設置，這需要實踐經驗不斷積累才能找到答案。需要注意的是，如果Ramp-up period設置不當，有可能100個線程只能產生1個並發請求。
參考資料：
《全棧性能測試修煉寶典JMeter實戰》