1.開始之前，先介紹下壓測的一些基本插件:線程組常用分為三類:user thread , step thread ,ultimate thread :
user thread :最通用的最原始的線程實現；分為循環實現線程，可以實現線程delay延時；
step thread :能夠實現一些較復雜場景，比如常見爬坡類類型，以及持續在線場景
This Group will start 10 threads：這次的測試總共會起10個線程。 First , wait for 0 seconds：等待0s后開始起線程，也就是不等待直接起線程。 Then start 0 threads；從0個線程開始持續增加。 Next，add 2 threads every 3 seconds：每增加2個線程后會運行3s，再起余下的2個線程，再運行3s，以此類推。 Using ramp-up 6seconds：前面每起2個線程的時候花6s，與上面結合起來即6s內起2個線程，運行3s，然后再再6s內再起2個線程，再運行3s，以此類推。 Then hold load for 30 seconds. ：全部的線程起來后，運行30s 后開始停止。 Finally , stop 2 threads every 1 seconds：最后停止線程，2個線程停一次，等1s再
ultimate thread:
參數含義解釋: Start Threads Count：當前行啟動的線程總數 Initial Delay/sec：延時啟動當前行的線程，單位:秒 Startup Time/sec：啟動當前行所有線程達峰值所需時間，單位:秒 Hold Load For/sec：當前行線程達到峰值后的穩定加載時間，單位:秒 Shutdown Time：停止當前行所有線程所需時間，單位:秒
2。關於同步定時器syn timer:
它有兩個參數:1.模擬用戶組數量，我這里把他稱為集合釋放閾值意思,就是當你想實現用戶達到一定數量時一起同時請求目的，他會根據你的 timeout時間設置決定什么時間發送已經集結的thread請求requests，2. time out in millionseconds 簡稱ttl ，意思是超時時間
你需要注意的有以下:1.模擬用戶數量的值不能夠大於線程組user thread 的線程數所填寫的值，其次對於syn timer 的超時時間為0表示定時器會等到模擬用戶數達到設置數量才會一次發出所有請求，非0時，如過設置時間內還未達到集合要求數量，將不會在等待后面還未到達請求，直接發送所有已集結threads 的requests;
2.如果你的模擬用戶組數量也就是集結數量默認為0，它會按照user thread 線程數進行等待，對於超時時間研究過一個小技巧就是time>模擬用戶組數量*1000/user thread number/loop count 可以避免因為設置 timeout =0 時，出現一直等待模擬用戶組數量卡死現象情況
3.關於插件: tps trt, activate thread ,監控匯總以及圖形插件下載地址:Extras.jar,下載完成后丟進jmeter 的lib/ext下面重啟jmeter插件就會生效
https://github.com/chen1932390299/JavaProject/raw/JmeterJavaBranch/lib_jtlChange/ext/JMeterPlugins-Extras.jar
當然如果你有其他的插件也想下載可以使用下面這個old jmeter plugin,不知道什么時間放棄維護，應該是國內源download速度比官網快很多：
https://jmeter-plugins.org/downloads/old/
4.數據分析:對於壓力測試很多人都不考慮持續壓力測試的這種情況，以較短時間的一段數據來衡量整個服務性能數據是很不科學的:
首先什么是虛擬用戶數，什么是並發量，甚至有些pm在表達自己或者用戶需求時都沒搞清並發和用戶數的具體區別，jmeter用戶模擬是通過線程實現，一個線程代表着一個虛擬用戶；很多新手一上來就是線程數等於並發數堆上去，就是干，更有甚者直接拿着一台windows模擬出5000,甚至更高的數據並發，被很多經驗豐富的技術人員所diss,實際上根本不能達到效果，而且一旦出現ko你分不清ko的請求哪些是服務器無法處理導致的error還是因為本地內存資源耗盡導致的request的error；
或許有人會講了並發本就沒有真正意義的並發的確我們並發不可能一點點時間都不差，我們終不過是實現一個更接近並發場景的場景構造就和我們極限求導一個思想，無限逼近那個理想效果；廣義並發我們稱為同一時刻發生的所有用戶行為，可以做不同的事，也可以做相同的事；狹義來講，我們認為並發是同一時間做相同的事；那么有沒有想過為什么不能上面那些新手那樣直接懟就是干呢，首先線程啟動是又先后順序的，其次壓力機器的資源是有限的當達到上限會對線程排隊；再者，單台機器內存有限不可能無限制啟動5000甚至上萬線程那樣本地早就oom了，想要實現更高的並發需要通過分布式壓測來解決資源問題分攤請求壓力一台master執行機器可以對應多台slave 負載機器實現高並發的請求
計算公式:
concurrent = requests_totals*avgtime_rep/time_totals_continue
request_totals約等於 tps*time_totals_continue
也有一些網友采用tps*avgtime/1000方式這樣有一個風險就是如果你取到的波動的一個峰值或取到的剛好是波谷，這就意味着你的所有請求都的為你的這個tps值買單這是有很大風險的
整個推導過程以一段時間的數據請求總時間/持續壓測時間，來衡量這段時間的服務器實際並發量，通過計算來得到服務器在不同用戶並發下實際能達到的並發處理值也就是每秒處理的實際請求數作為實際並發值，因此我們也可以通過反向計推算出我們想達到某一並發所需要的虛擬用戶數,也就是userthreads數量；上面的公式來計算下面這組數據
首先明顯測試出的總的requests數量在10 user thread 持續60的時間內總的數量為13490那么，我們用上面的計算公式來驗證我們的計算是否與測試出來的一致：
total_requests=tps*time_totals_continue=228.2*60=13692與jmeter測試出來的13490的請求量只有1.5%的誤差，由此可見我們的計算是很接近實際的測試值的
但是這個只是一個大概值，其次隨着並發數量增加，本地資源耗費以及服務負載增加 user threads 與 並發concurrent 轉換率會由1:1 隨着thread數量增加，轉換率會越來愈低經驗來講一般到后面只有1：0.3的轉換率這也是很多壓測經驗者為什么根據user thread 的30%作為並發數的原因，而在linux會由於io,內存，cpu綜合性能優於windows轉換率能到達1:1.隨着並發增加也能依舊保持1:0.8的優秀轉換率，這些都是我和同事一起在工作過程中經過壓力統計觀測發現的一些有趣的事情:
以下是Extras的監聽器部分插件：
activate thread 活躍線程數監控:
transcations thrououtput/threads監控 :
rtt 響應時間監控:
transcations persecond 秒處理事務數 監控數據:
聚合報告:
插件功能解釋：
在文章的最后我想推薦一篇國外期刊給大家：讓你學習如何通過十二種方式去分析性能數據，如何成為一名優秀的專業的技術人員：
https://octoperf.com/blog/2017/10/19/how-to-analyze-jmeter-results/
