LoadRunner常見報錯日誌以及解決方案

1.Loadrunner報錯日誌

Action.c(13):錯誤-27727: Step download timeout (120 seconds) has expired when downloading resource(s). Set the "Step Timeout caused by resources is a warning" Run-Time Setting to Yes/No to have this message as a warning/error, respectively

解決方案:

修改“運行時設置-HTTP請求連接超時、HTTP請求接收超時”的值爲600s或者更長時間

Run-Time Setting(運行時設置) -- Internet Protocol -- Preferences -- Option -- Step download timeout(sec)改爲15000(根據需要可能更大)

2.Loadrunner報錯日誌:

Action.c(39):錯誤-27796:連接服務器“test0105.s1.diy.com:80失敗: [10061] Connection refused

有可能是服務器有太多的數據庫連接,提示連接被拒絕

解決方案:

可以讓開發嘗試調整:

1.數據庫最大連接數;

2. tomcat的最大併發數限制

3.Loadrunner報錯日誌:

Action.c(9):錯誤-27791:服務器“test0105*.s1.diy.com”已過早關閉連接

訪問時已經下載不到資源了,有可能是已經達到服務器資源的瓶頸了,可以查看服務器資源如CPU、負載等

4.Loadrunner報錯日誌:
Action.c(7): Error -27791: Server "10.10.0.88" has shut down the connection prematurely


借鑑51Testing網友提供的解決方案:
1)
、應用服務器死掉。小用戶時程序上的問題,程序上處理數據庫的問題
2)
、應用服務沒有死。應用服務參數設置問題。例如:在許多客戶端weblogic應用服務器被拒絕,而在服務器端沒有錯誤顯示,則有可能是weblogic中的server元素的acceptbacklog屬性值設得過低。如果連接時收到connection refused消息,說明應提高該值,每次增加25%
3)
、數據庫的連接
在應用服務的性能參數可能太小了
數據庫啓動的最大連接數(跟硬件的內存有關)
4)
、有時關閉防火牆如卡巴斯基也會解決如上問題


5,Loadrunner報錯日誌:

Action.c(43) Error -26612 HTTP Status-Code=500 (Internal Server Error) for "http//192.168.1.2227001/ulms/login.do"

500 Internal Server Error
IIS的HTTP 500內部服務器錯誤是經常碰到的錯誤之一,它的主要錯誤表現就是ASP程序不能瀏覽.但HTM靜態網頁不受影響。另外當錯誤發生時,系統事件
日誌和安全事件日誌都會有相應的記錄。
IE中的表現,當瀏覽以前能夠正常運行的asp頁面時會出現如下的錯誤:網頁無法顯示



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類似,只不過windows修改註冊表,具體修改註冊表中有TcpTimedWaitDelay和MaxUserPort項,鍵值在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]。因爲負載生成器的性能太好,發數據包特別快,服務器也響應特別快,從而導致負載生成器的機器的端口在沒有timeout之前就全部佔滿了。在全部佔滿後,就會出現上面的錯誤。執行netstat –na命令,可以看到打開了很多端口。所以就調整TCP的time out。即在最後一個端口還沒有用到時,前面已經有端口在釋放了。
1,這裏的TcpTimedWaitDelay默認值應該中是30s,所以這裏,把這個值調小爲5s(按需要調整)。
2,也可以把MaxUserPort調大(如果這個值不是最大值的話)。
四、問題描述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 來查看進程打開的句柄數。
五、問題描述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鋸齒型的變化,上升下降都很快,這應該是不太正常的。
---------------------------------------
實際測試中,可以用telent 站點看看是否可以連接進去,可以通過修改連接池中的連接數和適當增加應用內存值,問題可以解決。
六、問題描述Failed to connect to server
這個問題一般是客戶端鏈接到服務失敗,原因有兩個客戶端連接限制(也就是壓力負載機器),一個網絡延遲嚴重,解決辦法:
1、修改負載機器註冊表中的TcpTimedWaitDelay減小延時和MaxUserPort增加端口數。注:這將增加機器的負荷。
2、檢查網絡延遲情況,看問題出在什麼環節。
建議爲了減少這種情況,辦法一最好測試前就完成了,保證乾淨的網絡環境,每個負載機器的壓力測試用戶數不易過大,儘量平均每臺負載器的用戶數,這樣以上問題出現的概率就很小了。
七、問題描述Overlapped transmission of request to ... WSA_IO_PENDING
這個問題,解決方法:
1、方法一,在腳本前加入web_set_sockets_option("OVERLAPPED_SEND", "0"),禁用TTFB細分,問題即可解決,但是TTFB細分圖將不能再使用,附圖。

2、方法二,可以通過增加連接池和應用系統的內存,每次增加25%。
八、問題描述Deleted the current transaction ... since response time is not accurate
這個問題不多遇見,一般出現在壓力機器上發生ping值爲負數(AMD雙核CPU),可以重新啓動pc機或者打補丁,附圖。

九、問題描述HTTP Status-Code=500 (Internal Server Error) for
1、應用服務當掉,重新啓動應用服務。
2、當應用系統處於的可用內存處於閥值以下時,出現HTTP Status-Code=500的概率非常高,此時只要增加應用系統的內存,問題即可解決。
十、問題描述Failed to transmit data to network: [10057]Socket is not connected
這個錯誤是由網絡原因造成的,PC1和PC2上面都裝了相同的loadrunner 9.0,且以相同數量的虛擬用戶數運行相同的業務(機器上的其他條件都相同),PC1上面有少部分用戶報錯,PC2上的用戶全部執行通過。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章