提問1
如何在大併發測試下，讓登陸或者後續接口只執行一次？linux
回答
這個問題網上的答案其實不少，可是大多不靠譜。
好比推薦使用僅一次控制器，可是僅一次控制器對線程組無效；好比推薦跨線程組調用，可是這樣比較繁瑣，新人也搞不定；
其實只要各位對元件熟悉，這個問題很簡單shell
下圖100線程：
服務器
添加一個吞吐量定時器，選擇總數計算微信
下面這就ok了，是否是很簡單？cookie
提問2
大併發的登陸以後，後續接口在作併發的時候有一些session重複了，併發量越大，重複概率越高。如何保證後續併發的session不重複？session
回答
緣由實際上是由於jmeter的多線程存在競爭機制，那麼併發量很大的時候，就會有一部分線程下的請求搶到了一樣的session。
咱們能夠把這些登陸口令在併發登陸的時候先在本地保存一份哦，用來代替用戶名密碼作登陸參數！多線程
好比下圖所示的session併發
寫個小腳本把這些session保存下來tcp
後續併發的時候直接引用這些cookie就好了函數
可是這種也有缺點，腳本會略微的影響吞吐量
提問3
如何識別tps拐點
回答
先分析下面這張圖。下面這張圖上展現了階梯負載量，響應時間，tps三種數據
從圖上能看出來三個趨勢
1：tps升到一個相對高點以後，長期維持穩定，再也不升高
2：運行一段時間以後，響應時間開始逐漸升高，可是趨勢不明顯
3：隨着負載愈來愈高，tps長期保持穩定
分析：
在負載逐漸升高的狀況下，tps卻長期不變。這並非說明性能很穩定，而是說明咱們單位時間內的單線程tps是在逐漸下降的（單位時間tps/總線程）。
再分析響應時間，咱們的響應時間其實也是在逐漸升高，從側面反映出線程的tps是在降低的。
可是具體在多少負載量的時候咱們的瓶頸點已經到來？這張圖上很差計算，咱們換一個監聽器
這張圖的趨勢就比較明顯了。隨着負載升高，線程的tps逐漸達到一個高點，而後開始降低。那麼這個最高點就是咱們的性能瓶頸點
提問4
jmeter作壓測的時候，性能監聽圖形毛刺過多，看的想吐怎麼辦
回答
先秀一張圖階梯增壓的圖形，看看什麼是毛刺
這個場景是階梯增壓，每5s加10個，加到200，而後持續運行
能夠看出來tps曲線坑坑窪窪，高低不平，慘不忍睹，怎麼給它打磨一下？
修改setting
再回頭看一下圖形是否是沒那麼多毛刺了？
可是tps曲線依然波動很劇烈，這是咱們的壓力設置的不合理致使的
下面把ramp up值改爲10s，讓咱們的線程壓力沒那麼大
響應時間的劇增老是伴隨着tps的大跌
提問5
非GUI模式下作負載測試，修改參數好麻煩的說
回答
把關鍵參數都設置成變量，在非GUI下引用就好了，就像下面介樣子
寫一個shell腳本，參數所有引用一下
bat執行的時候就像下面這個樣子，hin輕鬆有沒有~
提問6
jmeter4444端口沒法監聽遠程服務器怎麼解決
回答
4444端口在阿里雲和騰訊雲服務上，是默認不開放的。想要監聽到，有兩種辦法，一種是防火牆開放4444端口，一種是更換端口。命令以下./startAgent.sh --udp-port 0 --tcp-port 1234
提問7
遠程機執行jmeter腳本，怎麼快速更換csv參數路徑？
只須要在參數路徑中加入一組函數，就能夠實現參數路徑自動定位，以下
${__P(user.dir,)}${__P(file.separator,)}test.txt
這一組函數的做用是，不論在linux仍是在本機，均可以自動切換路徑格式，不須要手動修改
Delay Thread creation until needed 是什麼意思？
jmeter的線程組裏面有一個Delay Thread creation until needed選項，以下圖。
不少人不理解這個選項是什麼意思，或者根據官方解釋，認爲它是延遲建立線程。可是延遲建立，在哪裏體現出來你？徹底搞不清。
咱們能夠經過jdk的監聽器看一探究竟。
不勾選延遲建立
線程組設置1500線程，ramp up設置10s，不勾選延遲建立，循環次數設置爲永遠。以下圖
運行腳本以後，咱們在活動線程監聽器裏面能夠看到線程確實是10s內建立完成，以下圖
可是咱們在jdk工具裏面再看一下線程建立的過程，會發現線程幾乎在1s內就所有啓動完成了，以下圖
勾選延遲建立
線程組設置1500線程，ramp up設置10s，勾選延遲建立，循環次數設置爲永遠。再次運行腳本，以下圖
結論
經過對比能夠發現，只有rump-up和delay-thread組合使用，纔可讓線程真正的實現延遲。jmeter上看到的延遲都是幻象。
本文分享自微信公衆號 - 測試驛棧（uhz2008_2008）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。