1、函数lrs_receive()
例：lrs_receive( socket1, "buf1", LrsLastArg );
当使用该函数时对Response Time影响很大，具体是什么原因。
解释：lrs_receive()默认的超时时间是10秒。如果receive的buffer和录制时的大小不一致，lrs_receive()会重新receive再做比较，直到超时为止。
官方说明：VuGen determines the expected size of the buffer from the recorded session. If the buffer size does not match (smaller or larger), lrs_receive rereads the incoming data carried by the socket, until the receive_timeout. By default the receive_timeout is 10 seconds. You can modify the timeout using lrs_set_recv_timeout or lrs_set_recv_timeout2.
2、函数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的连接问题？
测试经验：当一个socket连接的请求次数达到100次后，这个连接就不可用了，必须close后重新create。但由于我们的程序是异步实现的，发送一个请求后不是一直等待这个结果，而是通过请求、响应队列去获取结果，客户端定时去响应队列看自己的任务结果返回没有。这就造成了一个socket连接的请求次数不固定。当服务器空闲时，可以很快从响应队列获得结果，当服务器很忙时，需要更多的次数。
测试实验：
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)
Action.c(17): Error : socket0 - Software caused connection abort. Error code : 10053.
Abort was called from an action.
Ending Vuser...
Starting action vuser_end.
vuser_end.c(12): lrs_cleanup()
Ending action vuser_end.
问题最终得以进一步的确认，原来和测试所用的web服务器有很大关系。
由于我之前一直都是用tomcat、jboss做验证，所以都有这个问题。后来尝试将服务器改为IIS，结果测试意外的成功了！由此证明这个是和服务器类型相关的。估计是前者的服务器出于防止恶意***所作的策略。同样在weblogic服务器也可以测试通过。
但奇怪的是我用Rational Robot对两个服务器进行同样的测试确都没有问题。
后续我将进一步测试为何同样的tomcat服务器，在请求上有什么不同导致了决然不同的测试结果。
3、对lrs_send()和lrs_receive()函数执行时间的分析
Action()
{
lr_start_transaction( "send" );
lrs_send( "socket0", "buf14", LrsLastArg );
lr_end_transaction( "send", LR_AUTO );

lr_start_transaction( "receive" );
lrs_receive( "socket0", "buf15", LrsLastArg );
lr_end_transaction( "receive", LR_AUTO );
return 0;
}
4、结论
根据我的经验，对于BS结构的系统，用socket录制的脚本对比用http协议录制的脚本，加压的时候，TPS会低一半，而且交易成功率比较低。
5、编码方式
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种組合方式。