loadrunner 性能測試報error-27796的解決

網上觀點：

在註冊表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters裏，有以下兩個鍵值：
TcpTimedWaitDelay
MaxUserPort
1,這裏的TcpTimedWaitDelay默認值應該中是30s，因此這裏，把這個值調小爲5s（按須要調整）。
2,也能夠把MaxUserPort調大（若是這個值不是最大值的話）。

 

實踐：將TcpTimedWaitDelay默認值應該中是30s，因此這裏，把這個值調小爲5s，問題解決。

 

 load runner transaction 提示error:

Action.c(15): Error -27796: Failed to connect to server "10.9.34.101:80": [10061] Connection refused

問題：

 

曾經遇到過一個問題，在一次性能測試過程當中，使用http協議的多用戶向服務器發送請求。設置了持續時間，出現錯誤爲： 27796, Failed to connect to server 'hostname';port_ld': 'reason'.10048.（憑記憶寫的，不知道寫錯了沒有）

 

分析

 

由於負載生成器的性能太好，發數據包特別快，服務器也響應特別快，從而致使負載生成器的機器的端口在沒有timeout以前就所有佔滿了。在全 部佔滿後，就會出現上面的錯誤。執行netstat –na命令，能夠看到打開了不少端口。因此就調整TCP的time out。即在最後一個端口尚未用到時，前面已經有端口在釋放了。

 

官方的troubleshooting：

查看工具的troubleshooting，以下：

 

Message Code 27796 Failed to connect to server 'hostname';port_ld': 'reason'. Unable to connect to the specified server and port. Troubleshooting o      Try to address the reason provided for the connection failure. o      Try to access the application with a browser from the injector machine and from another machine (such as the recording machine). o      Check that you accurately specified the correct host name and port. o      Ping the host/port. o      Check if the server application you are trying to access is running. o      If you used a hostname, check if it was resolved to the correct address. o      Check if the server application is listening to the right port.

均不是解決之道。

 

成功的解決方法：

 

在負載生成器的註冊表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters裏，有以下兩個鍵值：

TcpTimedWaitDelay

MaxUserPort

1,這裏的TcpTimedWaitDelay默認值應該中是30s，因此這裏，把這個值調小爲5s（按須要調整）。

2,也能夠把MaxUserPort調大（若是這個值不是最大值的話）。

 

反覆驗證，問題解決。

 

 

 

 

 

在性能測試過程當中，你們均可能遇到過LR-27796錯誤，此類錯誤家常便飯..在走訪了各大論壇後，發現大俠們給出的各種的版本的27796錯誤，那麼27796是如何產生的呢？接下來跟你們分享下個人所得與感想

在測試一個web站的接口項目中，出現了大量的27796錯誤（此報錯代碼有不少種錯誤提示，好比：27796— Failed to connect to server、27796—timeout、27796-No Route To Host等 ），根據LR的幫助提示是修改註冊表的兩個鍵值後方可解決，我試着修噶了註冊表，重啓了機器，在喜氣沖沖的進行新的一輪壓測過程當中發現，錯誤木有解決，依然存在27796錯誤。我開始在網上搜索此問題的處理辦法，說法雲雲：一、重啓機器、二、修改註冊表、三、更換操做系統（囧）我發現對我木有效果，出現錯誤的請求佔總請求的20%左右，這個比例壓測是無任何意義的！心灰意冷....

我開始從第一個27796— Failed to connect to server開始查找緣由，若是出現鏈接失敗，確定是客戶端與服務器端的通訊出現了問題致使的，不論外界緣由，實質就是通訊!
我試着使用網絡工具wireshark在LoadRunner開啓時，抓取通訊信息。問題出現了，在監測通信過程當中發現，問題出如今第二次握手，客戶端已經發出syn包，但服務器端沒有接受到syn包，
當timewait三秒鐘後再次發出syn包，服務器端能夠接收到此包，問題出現了，就是說這個請求在沒有創建鏈接時就出現錯誤了，神奇了！！！
客戶端與服務器端
創建鏈接以下：
第一次　　第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；SYN：同步序列編號(Synchronize Sequence Numbers)。第二次　　第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態； 
　　

三次握手

第三次　　第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

問題找到緣由了，那麼這些不一樣的27796有那些問題，如何產生的呢？

答案1：你們可能有手工編寫腳本的習慣，你們使用最多的協議應該是web/http協議，那麼GET、POST請求是最多見的，例如：web_url("www.baidu.com",                 "URL=http://www.baidu.com", 
                "Resource=0", 
                "RecContentType=text/html", 
                "Referer=", 
                "Snapshot=t2.inf", 
                "Mode=HTML", 
                LAST);
這段代碼中咱們來分析下，若是把以上代碼修改成
     web_url("www.baidu.com",                 "URL=http://www.baidu.com",
                LAST);
請 求是否成功？答案是確定是，能夠發起get請求。那麼你們實驗過沒有若是這樣的話，在壓測過程當中是否出現過問題？LR會出現27796錯誤，你們能夠實驗 下，那麼問題出在那呢？問題就出如今本身的代碼中，缺乏RecContentType=text/html類型致使GET請求出現問題，服務器端沒法識別 請求攜帶的標示，因此本身的代碼編寫是27796產生的一部分

緣由2：這個是摘自百度的 帖子"由於負載生成器的性能太好，發數據包特別快，服務器也響應特別快，從而致使負載生成器的機器的端口在沒有timeout以前就所有佔滿了。在所有佔 滿後，就會出現上面的錯誤。執行netstat –na命令，能夠看到打開了不少端口。因此就調整TCP的time out。即在最後一個端口尚未用到時，前面已經有端口在釋放了"
說白了點，就是端口沒有釋放掉timeout狀態，沒有恢復到監聽的狀態，因此此時作好的辦法就是，重啓電腦恢復這些端口占用的狀態，當重啓機器後，查看狀態netsat -nao 後，若是恢復到正常端口的狀態，就能夠再次進行性能測試了。

緣由3：第三個緣由
在 性能測試i過程當中，可能出現服務器資源利用率太高，致使創建鏈接失敗現象，此類錯誤應該查看服務器的資源利用率，若是出現了資源利用太高現象，27796 的錯誤也會在此時產生！27796的錯誤通常都是因爲創建鏈接失敗而致使的，創建鏈接失敗的緣由有不少種狀況，你們只要明白其中27796的產生錯誤的實 質就能夠了，在你們測試過程當中歡迎你們跟帖，在什麼狀況出現的這種錯誤，如何解決的繼續下去！