1. 程式人生 > >【loadrunner】實踐中淺析集合點和思考時間對TPS的影響

【loadrunner】實踐中淺析集合點和思考時間對TPS的影響

問題背景:使用Loadrunner加壓的方式與開發使用開發的工具加壓的方式,1000併發的時TPS獲取的值差距非常大,並且Loadrunner加壓的方式TPS無法遞增。

實際原因:總體分析,猜想可能產生的原因:

1、客戶端傳送請求慢(設定思考時間和迭代時間導致);

2、程式處理能力;

3、網路問題。

       為了定位問題,先從這三方面出發,開始從最簡單的問題排除,順序為:3->1->2,經過排查,網路問題和客戶端請求慢的沒問題,以為是程式問題,但是通過開發提供的工具進行測試,發現程式的處理能力是可以的,tps是比預期的還大,為了解除疑惑,能準確定位問題所在,只能重新分析幾次,經過多輪測試,發現客戶端的指令碼中設定或未設定集合點時,影響到客戶端傳送請求次數,結果中的

tps也相差很大,最終確定問題就在“集合點”上。既然是集合點的問題,那就解析一下集合點為什麼會產生如此結果,原因很簡單,集合點函式在執行場景時,每個虛擬使用者都需檢查一下集合點的策略設定,如果不滿足策略,虛擬使用者只能在集合點處於等待狀態,直到集合點策略滿足後,方可執行下一輪操作,如果虛擬使用者傳送的請求在伺服器程式處理的時間不一致,就會形成較大的時間差等待或超時,所以本次測試tps無法增加的問題,在設定了集合點函式。

解決方案:如果需要獲取某業務的最大處理能力的時候,需要將思考時間和集合點去掉,以保證指令碼能夠最快的執行,使伺服器的處理能力達到最高。但需要注意,持續時間不能過長,伺服器得不到暫時的緩衝,我們將會看到記憶體持續消耗的現象。

反思:效能關鍵指標的理論依據與現實測試方法和業務應用的結合,是必須,且重要的。