一个不错的socket帖

ppent 发表于 2006-12-1 16:32

关于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的连接问题？

Wily 发表于 2006-12-1 17:06

[quote]原帖由 [i]ppent[/i] 于 2006-12-1 16:32 发表
我的测试经验是当一个socket连接的请求次数达到100次后，这个连接就不可用了，必须close后重新create。
... [/quote]

被测系统的操作系统是什么？Windows? Linux?

ftp传输大文件，在一个TCP连接上传输的次数肯定比100多得多。如果阁下说的这个问题存在，肯定是被测系统的后台软件质量不高造成的。

总之，阁下的这个经验不具备通用性。

ppent 发表于 2006-12-1 17:33

你有点误会了，是一个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.

Wily 发表于 2006-12-2 19:34

严重NOD.

看来楼上是一个勤学习肯钻研的好青年。

LR的socket实现确实存在一些问题。 根据我的经验，对于BS结构的系统，用socket录制的脚本对比用http协议录制的脚本，加压的时候，TPS会低一半，而且交易成功率比较低。 为此我们专门做过实验。

尽量不要用LR的socket协议的脚本进行测试，否则的话测试结果不准确。

希望这样的好贴越来越多！

ppent 发表于 2006-12-4 10:25

顶一下

ppent 发表于 2006-12-9 18:32

问题最终得以进一步的确认，原来和测试所用的web服务器有很大关系。
由于我之前一直都是用tomcat、jboss做验证，所以都有这个问题。后来尝试将服务器改为IIS，结果测试意外的成功了！由此证明这个是和服务器类型相关的。估计是前者的服务器出于防止恶意攻击所作的策略。同样在weblogic服务器也可以测试通过。
但奇怪的是我用Rational Robot对两个服务器进行同样的测试确都没有问题。
后续我将进一步测试为何同样的tomcat服务器，在请求上有什么不同导致了决然不同的测试结果。