關於lrs_create_socket的連接問題
我的測試經驗是當一個socket連接的請求次數達到100次後，這個連接就不可用了，必須close後重新create。但由於我們的程序是異步實現的，發送一個請求後不是一直等待這個結果，而是通過請求、響應隊列去獲取結果，客戶端定時去響應隊列看自己的任務結果返回沒有。這就造成了一個socket連接的請求次數不顧定。當服務器空閒時，可以很快從響應隊列獲得結果，當服務器很忙時，需要更多的次數。
請問是否有辦法可以解決lrs_create_socket的次數限制問題？
附腳本示例如下：
lrs_create_socket("socket0", "TCP", "LocalHost=0", "RemoteHost=localhost:8080", LrsLastArg);
lrs_send("socket0", "buf56", LrsLastArg);
lrs_receive("socket0", "buf57", LrsLastArg);
GetJobID();
do{
lr_think_time(0.3);
lrs_send("socket0", "buf58", LrsLastArg);
lrs_receive("socket0", "buf59", LrsLastArg);
}while(!CheckStatus());
其中buf56、57是發送請求，buf58、59是循環去獲取結果，因此請求數不固定，這是應該如何解決lrs_create_socket的連接問題？ [quote]原帖由 [i]ppent[/i] 於 2006-12-1 16:32 發表
我的測試經驗是當一個socket連接的請求次數達到100次後，這個連接就不可用了，必須close後重新create。
... [/quote]
被測系統的操作系統是什麼？Windows? Linux?
ftp傳輸大文件，在一個TCP連接上傳輸的次數肯定比100多得多。如果閣下說的這個問題存在，肯定是被測系統的後臺軟件質量不高造成的。
總之，閣下的這個經驗不具備通用性。 你有點誤會了，是一個socket連接在多次請求後有問題。
我認爲這個問題不是被測系統的問題，而是LR本身的問題。
以下是我做的測試實驗：
1、用socket方式錄製訪問某個網頁並保存
2、添加循環方式去訪問
結果證明在socket請求次數達到100後即無法再次訪問了（少數次數可以達到一百零幾）。
同樣的測試方式在Rational Robot中可以通過。
腳本如下：
#include "lrs.h"
int i;
Action()
{
lr_think_time(1);
lrs_create_socket("socket0", "TCP", "LocalHost=0", "RemoteHost=appsvr01:8080", LrsLastArg);
i=1;
do{
lrs_send("socket0", "buf0", LrsLastArg);
lrs_receive("socket0", "buf1", LrsLastArg);
lr_output_message("-------------lrs request times: %d ", i);
i++;
lrs_send("socket0", "buf2", LrsLastArg);
lrs_receive("socket0", "buf3", LrsLastArg);
lr_output_message("-------------lrs request times: %d ", i);
i++;
lrs_send("socket0", "buf4", LrsLastArg);
lrs_receive("socket0", "buf5", LrsLastArg);
lr_output_message("-------------lrs request times: %d ", i);
i++;
lrs_send("socket0", "buf6", LrsLastArg);
lrs_receive("socket0", "buf7", LrsLastArg);
lr_output_message("-------------lrs request times: %d ", i);
i++;
}while(i<200);
return 0;
}
日誌如下：
...
lrs_send(socket0, buf2)
Action.c(21): lrs_receive(socket0, buf3)
Action.c(22): -------------lrs request times: 98
Action.c(24): lrs_send(socket0, buf4)
Action.c(25): lrs_receive(socket0, buf5)
Action.c(26): -------------lrs request times: 99
Action.c(28): lrs_send(socket0, buf6)
Action.c(29): lrs_receive(socket0, buf7)
Action.c(29): Mismatch (expected 1249 bytes, 1268 bytes actually received)
Action.c(30): -------------lrs request times: 100
Action.c(16): lrs_send(socket0, buf0)
Action.c(17): lrs_receive(socket0, buf1)
[color=Red]Action.c(17): Error : socket0 - Software caused connection abort. Error code : 10053.[/color]
Abort was called from an action.
Ending Vuser...
Starting action vuser_end.
vuser_end.c(12): lrs_cleanup()
Ending action vuser_end. 嚴重NOD.
看來樓上是一個勤學習肯鑽研的好青年。
LR的socket實現確實存在一些問題。 根據我的經驗，對於BS結構的系統，用socket錄製的腳本對比用http協議錄製的腳本，加壓的時候，TPS會低一半，而且交易成功率比較低。 爲此我們專門做過實驗。
儘量不要用LR的socket協議的腳本進行測試，否則的話測試結果不準確。
希望這樣的好貼越來越多！ 頂一下 問題最終得以進一步的確認，原來和測試所用的web服務器有很大關係。
由於我之前一直都是用tomcat、jboss做驗證，所以都有這個問題。後來嘗試將服務器改爲IIS，結果測試意外的成功了！由此證明這個是和服務器類型相關的。估計是前者的服務器出於防止惡意攻擊所作的策略。同樣在weblogic服務器也可以測試通過。
但奇怪的是我用Rational Robot對兩個服務器進行同樣的測試確都沒有問題。
後續我將進一步測試爲何同樣的tomcat服務器，在請求上有什麼不同導致了決然不同的測試結果。