app每秒并发数_性能测试连载 (38) jmeter 线程数与性能测试的负载模式
????????????點擊跳轉>>jmeter--由淺入深學性能系列
需求
下面有3個場景,思考一下在jmeter里面如何設計
場景1:有一個項目,500用戶同時登錄,響應時間能達到多少場景2:考勤打卡,最大吞吐量能達到多少(每秒最大能完成多少筆打卡業務)場景3:銀行業務,如果需要支持1分鐘內完成3000筆取款操作,平均每秒能支持多少用戶同時取款完成
負載模式
性能測試中的負載模式有兩種。第一種是并發用戶模式(虛擬用戶模式)
????并發用戶是指虛擬并發用戶數,從業務角度,也可以理解為同時在線的用戶數。從客戶端的角度出發,摸底業務系統各節點能同時承載的在線用戶數,可以使用該模式設置目標并發,也就是 jmeter 里面的線程數。
第二種是RPS 模式(吞吐量模式)
??? RPS(Requests Per Second)是指每秒請求數。RPS 模式即“吞吐量模式”,通過設置每秒發出的請求數,從服務端的角度出發,直接衡量系統的吞吐能力。
場景設計
場景一分析
場景一就是典型的并發用戶模式。
????我們在用jmeter設計第一種場景的時候,可以用線程數去模擬并發用戶。如下圖
設置500線程去模擬500用戶;一次迭代表示每個線程的請求只發起一次;集合點500表示這500線程將在同一時間發起請求
場景二分析
場景二就是典型的吞吐量模式了。
????為什么要設計這種模式呢?因為我們通常談到壓力都是從客戶端去考慮的,也就是先知道并發用戶數有多少,然后再去發起壓力。但是如果不知道并發數的話,我們是不是就沒有辦法去測試了?所以后來從阿里衍生出了一個RPS模式,就是繞過并發數的計算,直接通過吞吐量去直接衡量服務端的性能。吞吐量是衡量系統性能的唯一標準。
????設計第二種場景的時候,我們就需要考慮吞吐量了。我們一般通過負載測試來找到吞吐量的拐點。
負載測試:持續穩定地增加系統的負載,測試系統性能的變化,找出系統瓶頸和性能拐點
????如果用rps壓力模式的話,這里所謂的增加系統負載,就是指的增加每秒請求數。如下圖rps定時器
下圖表示我在60s內將rps穩定的加到400/s
下圖表示監聽到的tps數據
場景三分析
????場景三其實也是一種吞吐量模式,但是這里的吞吐量不再是完成的請求數,而是完成的業務數,或者叫事物
業務時間
????支撐1分鐘內的3000筆取款操作,這里的意思就是1分鐘內完成3000筆取款的業務。怎么才算完成業務呢?事實上我們一筆取款機取款業務的完成時間需要從打開頁面發起請求開始計算,到響應完成,然后取款機給出結果讓用戶看到為止,中間還要包括思考時間。所以單筆取款業務時間=瀏覽器渲染時間+連接時間+思考時間+服務處理時間
平均并發數
????我們知道了一分鐘完成3000筆業務的需求,業務時間也可以計算出來。那么平均并發數是什么意思?這里的平均并發數指的是平均每秒有多少用戶同時取款完成,才能達到這個一分鐘3000的業務量。假設我的服務處理+瀏覽器渲染時間是2s,思考時間是8s。計算平均并發數的公式如下:
????平均并發=(單筆業務時間*業務總量)/業務時間= (10 X 3000)/60=500/s????也就是說,平均每秒有500個用戶取款,能達到我的預期業務量場景設計如下圖
????????點擊下方 閱讀原文,有免費的jmeter基礎課程視頻在線觀看哦~
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的app每秒并发数_性能测试连载 (38) jmeter 线程数与性能测试的负载模式的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Windows系统版本判断
- 下一篇: MFC列表控件ListControl和树