LR负载测试问题，请教各位达人！
小弟刚学LR没几天，现在碰到一个比较奇怪的问题，测试环境如下：有两个用Windows Sockets编写的服务端程序和客户端程序，服务端程序先运行，客户端程序启动后向服务端发送一条消息，服务端收到消息便向客户端传送一个4M多的文件，客户端发送完消息后也向服务端传送一个4M多的文件，最终客户端和服务端接收文件完毕便结束脚本的录制。现在碰到的问题是：在脚本录制过程和录制完回放过程中，客户端和服务端文件的传送都是正常的，很快就能传完，但当在LR控制器中运行生成的脚本时，服务端向客户端传送文件正常，而客户端向服务端传送文件却出奇的慢，运行了大约20分钟只传送了300K，最终控制器中显示Vuser运行结果为通过，但服务端却只接收了300多K，文件没有接收完整，即使只有一个Vuser也是如此；通过更改脚本的运行时设置再试也是如此。
不知有没有人知道该问题可能的原因，请不吝赐教，谢谢！ 有点类似于下载的处理。以前有达人处理过，到论坛上搜索下看看。 我看了一下关于下载的帖子，都是关于网站的上传和下载，而我提到的客户端和服务端是用windows socket编写的两个exe可执行程序，客户端执行过程中也不与用户交互，直接执行完毕。
今天下午又重新录制了一遍脚本，发现在Virtual User Generator中录制完脚本后，点击工具栏上的“运行”按钮（或者按F5）在Virtual User Generator中运行脚本时会出现同样的问题，Action.c文件中主要是由一对对的send/receive函数组成，如：lrs_send("socket0", "buf0", LrsLastArg); lrs_receive("socket0", "buf1", LrsLastArg);，send函数的执行没提示异常，但从第二条receive语句开始，执行到receive语句时时间会很长，且每次执行完毕receive语句就会在回放日志中提示“Mismatch (expected 42065 bytes, 4759471 bytes actually received)”或者“Mismatch (expected 32768 bytes, 0 bytes actually received)”这种异常。
貌似是LR录制的脚本在接收服务端的数据时出了问题，导致每次receive时间较长，进而影响到了后续的send操作，导致服务端数据接收过慢，但receive又为何出现接收异常呢？
页:
[1]
