loadrunner socket协议问题归纳（1）

前段时间测了loadrunner直接发送报文到socket上的性能测试。在此，稍微回顾整理下。

与socket通讯，有两种方式，一种是建立长连接，建立后，不停的发送，接收。另外一种是建立短连接，建立连接，发送报文，接收响应，关闭连接。两种方式server的开销不同。Loadrunner可以把建立连接（关闭连接）是否放在VUSER_INIT（VUSER_END）中设置以上两种通讯方式。

Step1:建立连接的代码如下： int sc=0; sc = lrs_create_socket("socket1","TCP","RemoteHost=131.252.83.233:15017",LrsLastArg);

if (sc == 0)

lr_output_message("Socket was successfully created ");

else

lr_output_message("An error occurred while creating the socket, Error Code: %d", sc);

step2:建立连接成功后，就需要往socket上发送报文，发送报文的代码如下：

lrs_send("socket1", "buf2", LrsLastArg);

Q1:那么有人会问这里的buf2是在哪里配置的？这个就需要我们打开脚本中的data.ws,这部分是放置是socket通讯发送和接收报文的。上面的发送报文的语句中buf2就需要在data.ws中配置。

配置例子如下：

send buf2 275 "/x30/x32/x37/x31”

这里我们分别解释一下各字段的含义：

第一个符号“send“是代表buf2是发送报文。Data.ws中的报文有两种，一种是发送buffer,一种是接收buffer,各自对应的符号标记为”send”和”recv”

第二个符号是buffer名称，

第三个符号”275”是buffer长度，这里需要说明一下，send类型的buffer，loadrunner是根据下面配置的buffer内容来计算实际buffer长度的，因此对于send类型的buffer,这里的buffer长度只作为参考，实际上是无意义的。而recv类型的buffer，这里配置的buffer长度就必须特别注意了，loadrunner会根据配置的长度去接收socket上内容，loadrunner会尝试去读取一个符合配置长度的buffer内容。第二行是buffer内容，对于”recv”类型的buffer，loadrunner实际上是只是在log中会打印出expect receive buffer ＝你配置的buffer内容。

Q2:这里有人会再问，类似web(http)协议，发送的报文需要参数话，怎么做。Loadrunner里面操作也很简单，选中需要参数话的报文内容－》右键――》参数化。后期的操作与web协议一样。

Q3：这里有人会接着问，buffer里面配置的内容，以什么的编码方式，能够自行设定吗？这里我们可以再看loadrunner的配置，recording options,这里有一项配置，translation table. LoadRunner编码方式分为：ASCII码、EBCDIC码。如果选择Translation Tables中“None”方式，就是ASCII编码；其他都是选择EBCDIC编码方式，比如 00250352。其实Server是用0025方式编码，Client是用0352方式。 LoadRunenr有自己的ebcdic字典，路径是“/ebcdic”。 EBCDIC码：8位编码，可表示256个字符。EBCDIC是Extended Binary Coded Decimal Interchange Code之缩写，成为扩展式2进制10进数交换码或称扩展式BCD码。它是以左边4个区域位元(Zone bit)及右边4个数位位元合計8个位元組的资料码，一共可組合2的8次方=256种組合方式。 Note that the following functions overwrite the same internal buffer (user buffer): o lrs_ascii_to_ebcdic o lrs_ebcdic_to_ascii o lrs_get_received_buffer o lrs_get_static_buffer o lrs_decimal_to_hex_string

Step3:发送成功后，需要接收报文，一般判断测试是否通过是根据返回报文中的内容是否符合预期值来确认transaction是否通过。这里示例代码如下：

lrs_receive("socket1", "buf3", LrsLastArg);

lrs_save_param_ex("socket1", "received", "buf3", 0, 90,"ebcdic", "Response1");

lr_output_message ("消费Response: %s", lr_eval_string(""));

position=(char*) strstr(lr_eval_string(""),

lr_eval_string("0170100400"));

if(position==NULL)

lr_end_transaction("消费", LR_FAIL);

else

lr_end_transaction("消费", LR_PASS);

Q4:这里有人会问，为什么我的代码执行到lrs_receive的时候，log里面打印Waiting for writable socket 10 secs, 0 usecs，都需要等待10秒钟。是这样的，因为你在data.ws中定义了recv buffer的长度，例如你定义为100，但是socket上的返回buffer长度不是100，这时候，loadrunner会尝试再次去读取，直到读到长度为100的buffer才算成功。尝试多次，超时时间为多少？loadrunner默认为10s,所以你这里才会有等待10s的情况出现。我们可以指定超时时间：lrs_set_recv_timeout(1,10); 第一个参数是s,第二个参数是ms

当然实际情况，多数socket返回的响应buffer是变长的，这种情况下我们可以采取如下措施：

1.如果知道变长的recv buffer以什么结尾的话，可以设定loadrunner读取的时候，读到什么内容的时候停止读取。 lrs_set_receive_option(EndMarker, BinaryStringTerminator, "//x00//x07Mercury"); 具体lrs_set_receive_option还有多种用法，请参加帮助文档 2.或者我们手工指定loadrunner脚本，捕获多长的buffer。就需要使用如下代码来代替lrs_receive： lrs_receive_ex("socket1", "buf3", "NumberOfBytesToRecv=150", LrsLastArg); 到此为止，socket通讯单次的发送、接收应该基本没有什么问题了。至于多次交互涉及到的关联等技巧 ，请参考后续内容。