loadrunner返回脚本的动态数据判断

add:http://www.lxway.com/1845984.htm

-----------------------------------------------------------------

socket的脚本里面，我们在LG里面执行到lrs_receive的时候，回放脚本的时候（忽略think time的情况下）发现脚本回放很慢。但事务的响应时间并不长。在generator的日志里面看到，（Duration: 10.3054 Wasted Time: 10.0）。其中wasted time为10秒。

这个wasted time 是开销在哪呢？先介绍2个函数：

lrs_set_recv_timeout（param1，param2）第一个参数是s,第二个参数是ms,执行lrs_receive命令后，等待服务器返回消息的超时时间，即服务器的响应时间。

lrs_set_recv_timeout2 创建连接成功，接收到服务器返回的消息后，获取匹配消息的超时时间。lrs_receive接收到数据后，会和预期的数据长度进行比较，如果长度不匹配，它将重新从套接字上读取数据，直到超时为止。

再来看前面的wasted time 就好理解了，在data.ws中recv  buf3 4010 ，buf3的长度原本预期为401，录制(或者设置)时接收buffer的大小（4010）和回放时接收的buffer大小预期（401）的不一样，lrs_set_recv_timeout2这个函数就会一直读取缓存区的值，在这里浪费10秒（默认为10秒）。

   

   另外：当我们把这样的脚本放到controller中去执行，执行的结果就是响应时间是正常的，但是TPS很低，原因就是对于这个waiting time，LR并不把这个时间计入到响应时间中，但对于TPS来说，发起的笔数就相对来说少了，这个wasted time 相当于智能的迭代时间。

对于接收报文固定长度的，建议recv buf 长度写成和预期的一致，避免不必要的开销。

但我们也有可能遇到socket返回的响应buffer是变长的， 使用lrs_set_receive_option函数设置返回的属性，来实现这种动态的数据缓冲。

lrs_set_receive_option(EndMarker, EndMarker_None ) // 读取直到缓冲结束.

lrs_set_receive_option(EndMarker, StringTerminator , "\r\n") //读取直到"\r\n"符号出现 .

lrs_set_receive_option(EndMarker, BinaryStringTerminator , "\X00") 读取直到二进制符号"\\X00"出现

此方法适用于知道返回数据包的最后符号的情况，接收过程中读取此符号即停止接收。

2.或者我们手工指定loadrunner脚本，捕获多长的buffer。就需要使用如下代码来代替lrs_receive： lrs_receive_ex("socket1", "buf3", "NumberOfBytesToRecv=150", LrsLastArg);到此为止，socket通讯单次的发送、接收应该基本没有什么问题了。至于多次交互涉及到的关联等技巧 

Another option is mismatch:lrs_set_receive_option（Mismatch，MISMATCH_SIZE）