性能測試loadrunner使用共性問題匯總

轉發是對小編的最大支持

推薦

本微信公眾號底部菜單【免費】中有各類資料哦

2.3 共性問題

2.31 虛擬客戶腳本「Run-time Setting」中的線程和進程運行方式的區別？

如果選擇「Run Vuser as a process」，則場景運行時會為每一個虛擬用戶創建一個進程；選擇「Run Vuser as a thread」則將每個虛擬用戶作為一個線程來運行，在任務管理器中只看到一個mmdrv.exe，這種方式的運行效率更高，能造成更大的壓力，時默認選 項。

另外，如果啟用了IP欺騙功能，則先在Controller中選中Tools菜單下的「Expert Mode」，然後將Tools菜單下的「Options>General」標籤頁中的IP地址分配方式也設置為與Vuser運行方式一致，同為線程或進程方式。

2.32 thinktime與pacing的設置對腳本及場景的影響

在我測試的過程中在穩定性測試場景中有一次我對場景中的一個腳本取消了pacing設置，結果導致VU退出，出現了內存衝突的錯誤。

在我們測試中BancsLink_C63601_C63603_簡訊功能定製和刪除、 BancsLink_C60422_C60423_活期與定期批次轉出關聯、BancsLink_C67050_C67000_修改客戶信息提示等交易，不加thinktime時也會報錯。

首先我們要明確設置他們的意義。

Pacing是通過設置兩次迭代之間的間隔時間，來調整各個action之間的步調。從定義上來看，它是和iteration綁定在一起的。Pacing的設置可以調節系統壓力的大小，影響系統處理事務的能力。在場景運行中pacing的設置是很重要的。

Think time是通過設置思考時間，來模擬真實用戶在操作過程中的等待時間。從定義上來看，它是在iteration內部的某個action中各個步驟的間隔時間，主要目的在於模擬真實用戶操作情況，在測試中使虛擬用戶對業務的操作更接近實際。

示例：假設用戶進行一次操作會消耗5秒鐘的時間，即完成整個迭代需要5秒鐘。如果用戶不停頓，繼續第二次重複操作，則同樣耗費約5秒左右的時間。但是真實世 界中肯定是有停頓的。一個真正的用戶，做完一系列操作後，會間隔一段時間。假定用戶停頓了5秒，再第二次重複操作，則一共耗費10秒鐘時間。映射到 loadrunner中，就需要在一次iteration中，設置一個thinktime = 1秒，然後在兩個iteration之間，設置一個pacing為5秒。

2.33 在運行場景中兩個vu並發時交易出現錯誤，在腳本中沒有出現這種情況。

查看日誌發現兩vu所使用的參數值是一樣的，所以在接收報文時VU不能對應的找到自己的接收報文。

解決辦法

1、在場景中修改VU家在策略，有一次全部載入改為逐步載入。

2、改變取參策略，把數據分塊，然後分到固定的VU。

2.34題描述Deleted the current transaction ... since response time is not accurate

出現這個問題時TPS大幅下降，VU並沒有掉。這個問題不多遇見，在調試穩定性測試場景中遇到幾次。一般出現在壓力機器上發生ping值為負數時，可以重新啟動pc機或者打補丁，如果還不行把場景另存.

2.35 日誌緩存過小：to Log cache is too small to contain the message.

由於場景中Auto Log cache默認設置為1k，但是遇到報文較長的交易時自動日誌緩存的容量就太小了我們就得手動修改。

2.36 運行中掉VU。

1、出現Action.c(35): Error : save param parameter is invalid. Error code : 9005. Error -- memory violation : Exception ACCESS_VIOLATION received.

內存衝突的問題很普遍，有些程序設置之間的衝突也會導致這個錯誤，就腳本里來講，HTTP錄製的腳本裡面關聯錯誤會導致內存衝突；在socket協議的腳本里判斷成功時我們一般採用字母、數字與存儲在緩衝區里的報文做匹配，但是我們存在緩衝區裡面的報文是二進位格式的，所以在場景中也會造成內存衝突，最後掉VU。可能一個很小的問題就會引起內存衝突。

2、內存資源不足：腳本中的事務執行後沒有釋放buffer，最好在每個事務結束後就釋放buffer。

3、壓力過大：壓力過大導致本地存儲收回報文的存儲空間不足，寫不了日誌也會掉VU

4、參數取值不正確也可能導致掉VU

5、系統自身原因。

總體來說，解決方法就是調整腳本、分成多台壓力機進行測試。

2.37 為什麼Windows系統中的CPU、內存等資源仍然充足，但是模擬的用戶數量卻上不去?

在Windows計算機的標準設置下，操作系統的默認限制只能使用幾百個Vuser，這個限制與CPU或內存無關，主要是操作系統本身規定了默認的最大線程數所導致。要想突破Windows這個限制，須修改Windows註冊表。以Windows XP Professional為例。

(1)打開註冊表後，進入註冊表項HKEY_LOCAL_MACHINE中的下列關鍵字：SystemCurrentControlSetControlSession ManagerSubSystems。

(2)找到Windows關鍵字，Windows關鍵字如下所示：

%SystemRoot%system32csrss.exe bjectDirectory=Windows

SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

ProfileControl=Off MaxRequestThreads=16

SharedSection=1024,3072,512關鍵字的格式為xxxx,yyyy,zzz。其中，xxxx定義了系統範圍堆的最大值(以KB為單位)，yyyy定義每個桌面堆得大小。

(3)將yyyy的設置從3072更改為8192(即8MB)，增加SharedSection參數值。

通過對註冊表的更改，系統將允許運行更多的線程，因而可以在計算機上運行更多的Vuser。這意味著能夠模擬的最大並發用戶數量將不受Windows操作系統的限制，而只受硬體和內部可伸縮性限制的約束。

2.38問題描述open many files

問題一般都在壓力較大的時候出現，由於伺服器或者應用中間件本身對於打開的文件數有最大值限制造成，解決辦法：

1、修改操作系統的文件數限制，aix下面修改limits下的nofiles限制條件，增大或者設置為沒有限制，盡量對涉及到的伺服器都作修改。

2、方法一解決不了情況下再去查看應用伺服器weblogic的commonEnv.sh文件，修改其中的nofiles文件max-nofiles數增大，應該就可以通過了，具體就是查找到nofiles方法，修改其中else條件的執行體，把文件打開數調大。修改前記住備份此文件，防止修改出錯。

3、linux上可以通過ulimit –HSn 4096來修改文件打開數限制，也可以通過ulimit -a 來查看。

4、linux上可以通過lsof -p pid | wc -l 來查看進程打開的句柄數。

2.38 LoadRunner與伺服器連接時遇到的問題

（1）ERROR:sck connect Aborted

這種錯誤一般是軟體造成連接中斷。由於軟體錯誤，造成一個已經建立的連接被取消，比如LoadRunner自身的bug，在發報文時多位。典型情況下，這意味著連接是由於協議或超時錯誤而被取消的。

（2）ERROR：Failed to connect to server

這個問題一般是客戶端鏈接到服務失敗，原因有兩個客戶端連接限制（也就是壓力負載機器），一個網路延遲嚴重，解決辦法：

1、 修改負載機器的tcpdelaytime註冊表鍵值，將其改小改小；

2、 檢查網路延遲情況，看問題出在什麼環節；

為了減少這種情況，最好測試中有個乾淨的網路環境，每個負載機器的壓力測試用戶數不易過大，盡量平均每台負載器的用戶數，這樣以上問題出現的概率就會減小。

（3）ERROR:has shut down the connection prematurely

分為以下三種情況：

1.應用訪問死掉

小用戶時：程序上的問題或資料庫的問題 ，應該查看一下sql執行效率和JAV的垃圾回收情況，具體定位問題。

2.應用服務沒有死

應用服務參數設置問題

例如：

在許多客戶端連接Weblogic應用服務大部分被拒絕，而在伺服器端沒有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過低。如果連接時收到connection refused消息，說明應提高該值，每次增加25％。　　Java連接池的大小設置，或JVM的設置等

3. 資料庫的連接

在應用服務的性能參數可能太小了

資料庫啟動的最大連接數（跟硬體的內存有關）

(4)ERROR: connection refused.

這種情況比較複雜，需要檢查幾個地方，不同的操作系統也會有不同的操作方式。

1．首先檢查是不是連接weblogic服務大部分被拒絕，監控weblogic的連接等待情況，可能與上面的一樣需要增加AcceptBacklog，如果沒有解決問題，還要增加增加連接池，調整線程數，（連接池數*Statement Cache Size）的值應該小於資料庫連接數的最大值。

2．查看伺服器的操作系統中是否對連接數做了限制，AIX下可以直接編輯limit文件，修改連接數、埠數的限制以及tcp連接等待時間的間隔大小。若是windows系統，則要修改其註冊表，修改TcpTimeWaitDelay（默認值30s）和MaxUserPort（可以調到小於最大值）項，鍵值在HKEY_LOCAL_MACHINESYSTEMCurrentControlSetTcpipParameters。因為當負載生成器的性能很好時，發數據包特別快，伺服器響應也很快，從而導致負載生成器的埠在沒有timeout之前就佔滿了。埠沒有可用的時候就會出現錯誤，。執行netstat-na命令，可以查看埠。如果調整了TCP的timeout，情況會好點，在埠還沒有佔滿前就有釋放的了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！