LoadRunner出現error問題及解決方法總結[轉載]

 一、Step download timeout (120 seconds)

 

  這是一個經常會遇到的問題,解決得辦法走以下步驟:

 

  1、 修改run time setting中的請求超時時間,增加到600s,其中有三項的參數可以一次都修改了,HTTP-request connect timeout,HTTP-request receieve timeout,Step download timeout,分別建議修改爲600、600、5000;run time setting設置完了後記住還需要在control組件的option的run time setting中設置相應的參數;

 

  2、 辦法一不能解決的情況下,解決辦法如下:

 

  設置runt time setting中的internet protocol-preferences中的advaced區域有一個winlnet replay instead of sockets選項,選項後再回放就成功了。切記此法只對windows系統起作用,此法來自zee的資料。

 

  二、問題描述Connection reset by peer

 

  這個問題不多遇見,一般是由於下載的速度慢,導致超時,所以,需要調整一下超時時間。

 

  解決辦法:Run-time setting窗口中的‘Internet Protocol’-‘Preferences’設置set advanced options(設置高級選項),重新設置一下“HTTP-request connect timeout(sec),可以稍微設大一些”;

 

  三、問題描述connection refused

 

  這個的錯誤的原因比較複雜,也可能很簡單也可能需要查看好幾個地方,解決起來不同的操作系統方式也不同;

 

  1、 首先檢查是不是連接weblogic服務過大部分被拒絕,需要監控weblogic的連接等待情況,此時需要增加acceptBacklog,每次增加 25%來提高看是否解決,同時還需要增加連接池和調整執行線程數,(連接池數*Statement Cache Size)的值應該小於等於oracle數據庫連接數最大值;

 

  2、 如果方法一操作後沒有變化,此時需要去查看服務器操作系統中是否對連接數做了限制,AIX下可以直接vi文件limits修改其中的連接限制數,還有 tcp連接等待時間間隔大小,wiodows類似,只不過wendows修改註冊表,具體修改方法查手冊,註冊表中有TcpDelayTime項;

 

  四、問題描述open many files

 

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

 

  1、 修改操作系統的文件數限制,aix下面修改limits下的nofiles限制條件,增大或者設置爲沒有限制,儘量對涉及到的服務器都作修改;

 

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

 

  五、問題描述has shut down the connection prematurely

 

  一般是在訪問應用服務器時出現,大用戶量和小用戶量均會出現;

 

  來自網上的解釋:

 

  1> 應用訪問死掉

 

  小用戶時:程序上的問題。程序上存在數據庫的問題

 

  2> 應用服務沒有死

 

  應用服務參數設置問題

 

  例如:

 

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

 

  Java連接池的大小設置,或JVM的設置等

 

  3> 數據庫的連接

 

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

 

  數據庫啓動的最大連接數(跟硬件的內存有關)

 

  以上信息有一定的參考價值,實際情況可以參考此類調試。

 

  如果是以上所說的小用戶時:程序上的問題。程序上存在數據庫的問題,那就必須採用更加專業的工具來抓取出現問題的程序,主要是程序中執行效率很低的sql語句,weblogic可以採用introscope定位,期間可以注意觀察一下jvm的垃圾回收情況看是否正常,我在實踐中併發500用戶和600用戶時曾出現過jvm鋸齒型的變化,上升下降都很快,這應該是不太正常的;

 

  六、問題描述Failed to connect to server

 

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

 

  1、 修改負載機器的tcpdelaytime註冊表鍵值,改小;

 

  2、 檢查網絡延遲情況,看問題出在什麼環節;

 

  建議爲了減少這種情況,辦法一最好測試前就完成了,保證乾淨的網絡環境,每個負載機器的壓力測試用戶數不易過大,儘量平均每臺負載器的用戶數,這樣以上問題出現的概率就很小了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章