執行緒組編輯區如下：
有點複雜，但是慢慢看下來，還是比較容易理解。
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實戰》