JMeter壓測筆記

每個資深測試工程師，必須掌握的測試工具，熟練使用Jmeter能大大提高工作效率。熟練使用Jmeter后， 能用Jmeter搞定的事情，你就不會使用LoadRunner了。Jmeter 是一款使用Java開發(fā)的，開源免費的，測試工具， 主要用來做功能測試和性能測試（壓力測試/負載測試）. 而且用Jmeter 來測試 Restful API, 非常好用。

                                       From Jmeter中文官網(wǎng)

本文是Jmeter操作筆記，

本文是Jmeter操作筆記，

本文是Jmeter操作筆記。

【前文從理論角度對比了lock鎖(Monitor)與讀寫鎖(ReadWriteLockSlim)的差異和使用場景，嘗試用Jmeter對lock、ReadWriteLockSlim壓測】

通過點擊jmeter解壓目錄.\apache-jmeter-5.4.1\apache-jmeter-5.4.1\bin\jmeter.bat 啟動jmeter，

上圖有一個默認的測試計劃，沒有任何內容。

線程組元件是任何測試計劃的開始點，可以配置要模擬的用戶數(shù)，所有的任務都是基于線程組。

右鍵單擊(Test Plan)>Add> Threads(Users)>Thread Group, 將添加線程組。

區(qū)域一：在采樣失敗后怎么處理？

1. Continue：繼續(xù)執(zhí)行接下來的操作；
2. Start Next Thread Loop：開始下一次循環(huán)；
3. Stop Thread：停止線程，退出該線程(不再執(zhí)行此線程的操作);
4. Stop Test：等待當前執(zhí)行的采樣器結束后，結束整個測試；
5. Stop Test Now：馬上停止測試；

區(qū)域二：線程屬性

1. Number of Threads(users): 線程數(shù)，相當于模擬的用戶數(shù)量;
2. Ramp-up Period(in seconds): 達到指定線程需要的時間，如果線程數(shù)是10， 時間設定為1s， 就是1s內嘗試加載10個線程；

未指定ramp-up period ,也就是說ramp-up period為0,JMeter 將立即建立所有線程。

3. Loop Count：循環(huán)次數(shù)，如果選擇[Forever]則一直執(zhí)行下去，直到手動停止。

旁白:  在某R周期內啟動了N個線程數(shù)， 進行了L次這樣的周期測試。
請求次數(shù)= 線程數(shù) * 循環(huán)次數(shù)

4. Duration：整個壓測的時長

此次我們主要測試 [多讀少寫]的場景，故我們添加http請求采樣器。

在特定線程組右鍵>Add>Sampler>Http Request:

基本使用方式，一點就通。

通過偵聽器 監(jiān)聽采樣結果：線程組右鍵>Add>Listener>[****],

這里添加幾個有效常見的偵聽器：View Results Tree、Summary Report、Aggregate Report、Aggregate Graph

在一個線程組內的線程是依次執(zhí)行的，我們建立兩個線程組分別測試

(讀寫比1:1)

(讀寫比10:1)

Label ：各個模擬測試的名稱
Samples ：各個測試的樣本總數(shù)
Average ：每個請求的平均響應時間
Median ：中值，即50%請求的平均響應時間
90%Line ：90%請求的響應時間
Min ：最小響應時間
Max ：最大的響應時間
Error% ：錯誤響應的概率，即無法響應的概率
ThroughPut ：吞吐量 – 默認情況下表示每秒完成的請求數(shù)（Request per Second）。
KB/Sec ：每秒從服務器端接收到的數(shù)據(jù)量。

貌似性能基本沒差異，====》 到Stack Overflow走一圈,    類似問題

https://stackoverflow.com/questions/4217398/when-is-readerwriterlockslim-better-than-a-simple-lock

There's no contention in this program. The Get and Add methods execute in a few nanoseconds. The odds that multiple threads hit those methods at the exact time are vanishingly small.

這個壓測中沒有爭用，_dict.TryGetValue 是o(1)的復雜度，速度很塊，多個線程在某時刻命中這個方法的概率極小，整個api代碼塊耗時幾納秒，壓測結果12ms，絕大部分都是在網(wǎng)絡上， 貌似要寫代碼測試了。

真是一個悲傷的故事，本文最終淪落為#JMeter操作筆記#。

筒靴們有其他意見或者想法，請留言賜教。  

源碼地址 https://github.com/zaozaoniao/RWLOCKTest

  多線程環(huán)境下，程序真是危機四伏

  面試官：平時開發(fā)中你用過讀寫鎖嗎？

  你管這叫"線程安全"?

 面試官：實現(xiàn)一個帶值變更通知能力的Dictionary

  如何主動清空.NET數(shù)據(jù)庫連接池？

  .Net線程同步技術解讀

點“贊”戳“在看”

體現(xiàn)態(tài)度很有必要!