概述
在jmeter中，只要提到併發，99%的同窗立馬想到線程組。須要多少併發就啓動多少線程組，這已經成了大部分人的共識。這種理解方式很明顯是把併發數和線程數的概念混淆了。線程組中不光有線程數，也有循環次數。然而你們在負載測試中都主動的忽略了循環的做用。jmeter中的循環和lr中的迭代是同樣的，都是爲了模擬出壓力，不要選擇性無視它微信
實驗
先列出下面兩個需求，你們能夠思考一下這兩個需求在jmeter裏面如何設置場景併發
需求1：我有一個頁面，須要測試一下最大支持多少用戶併發？
此時要計算的是最大用戶併發數，強調的是同時操做，也能夠理解爲同時發起請求
針對需求1咱們能夠經過RPS 定時器或者階梯加壓線程組測試每秒最大的請求數（壓測實戰分析性能拐點）工具
需求2：查詢功能，須要系統可以在5分鐘內能完成5000筆查詢業務，同時90%的用戶響應時間不超過3s。最大併發是多少？
此時不強調同時操做，而是強調業務量。也就是說不限制用戶的操做時序，不考慮人的效率。把人當作機器，只要在5分鐘內查詢數知足5000筆便可。可是具體有多少用戶才能在5分鐘內查詢5000次？它是由單次響應時間來決定的。這時就引入了一個常常被人討論的公式：最大併發數= （單次響應時間*業務量）/總的業務時間。個人單次響應時間越快，用戶每秒可點擊的次數就越多，那麼需求就越容易知足。性能
線程數和併發數
針對需求2，咱們如何在jmeter中設置場景？由上面的描述能夠知道，咱們能夠計算出最大併發數。那麼這個最大併發數對應的就是jmeter中的線程數。光有線程數不行，此時又引入了一個迭代的概念。假設單線程下，單次請求的平均響應時間是200ms，那麼這個單線程的請求1s內能夠迭代5次。若是有100個線程，那麼1s內就能夠完成500筆業務。5分鐘內完成的業務數就是5*60*500=15萬筆。回到咱們需求2，是否是遠遠超綱了？把線程數縮小，其實只須要4個線程，就能夠在5分鐘內超額完成5000筆業務了。4*5*5*60=6000測試
1-1
spa
如圖1-1，勾選循環永遠的意思就是不限制單位時間內的迭代次數，以此加載最大壓力。
注：若是循環次數設置了固定值，那麼下發那個持續時間的設置是無效的。線程組會優先根據你的固定循環次數去執行迭代。也就是說，固定循環次數的執行順序優於持續時間！可是若是循環次數設置爲永遠，再設置持續的時間，那麼就會根據你的持續時間去加載最大的壓力。.net
事物完成線程組（TPS線程組）
針對需求2，jmeter額外提供了一個線程組去知足它-- Arrivals Thread Group。在這個線程組中咱們給予預期的業務量和業務時間，系統會自動啓動線程去知足業務需求。線程
1-23d
如圖1-2，表示個人預期tps是50/s，在2s內達到預期值，同時保持這個tps運行20s，那麼22s內個人業務量是22*50=1100orm
1-3
如圖1-2，最大的系統併發數（啓動的線程數）是319
總結
咱們作性能測試，壓力都是人爲給予系統的。使用工具的目的也是爲了模擬出用戶的壓力場景
本文分享自微信公衆號 - 測試驛棧（uhz2008_2008）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。