本文详细介绍了在使用LoadRunner的Sockets协议进行录制和回放脚本时遇到的问题及解决方案，包括回放速度慢、缓冲区大小不匹配、动态关联和并发测试中的数据接收问题。通过调整接收超时时间、设置EndMarker选项，成功解决了这些问题，提高了脚本效率。
背景：
被测系统是一个使用.net framework 2.0开发的C/A/S结构的程序，APP是IIS6.0。由于LR8.1 FP4中增加了对.net framework 2.0的支持，本来想使用新增加的Microsoft .NET协议录制，无奈录制过程中遇到的问题多多，而网上对这个协议的资料又少之又少，时间紧的情况下只好先使用Sockets协议来进行录制，Microsoft .NET协议就留着以后再深入了解吧。
第一步：录制脚本。没什么可说的，一步步操作即可。
第二步：回放脚本
回放的过程中发现脚本回放的很慢，一个脚本在忽略think time的情况下回放竟然需要好几分钟，但事务的响应时间并不长。本以为在generator慢，在controller下会快一些，结果试了一下还是一样。
仔细查看回放log后发现在回放慢的事务中都包含了很长的wasted time，这就是回放慢的原因了。查找资料后才知道是由于录制时接收buffer的大小与回放时接收的buffer大小不同（Mismatch）产生的。LR中当遇到Mismatch时，会重新读取socket中的数据，直到超时为止。这个超时时间默认为10秒，可使用lrs_set_recv_timeout2函数进行修改。当脚本回放时mismatch很多时，自然就慢了，而且这个时间并不计入响应时间，而是计入wasted time。
修改了一些返回长度固定的buffer size，又把lrs_set_recv_timeout2设为5秒后，脚本回放时间大大缩短了&#
被测系统是一个使用.net framework 2.0开发的C/A/S结构的程序，APP是IIS6.0。由于LR8.1 FP4中增加了对.net framework 2.0的支持，本来想使用新增加的Microsoft .NET协议录制，无奈录制过程中遇到的问题多多，而网上对这个协议的资料又少之又少，时间紧的情况下只好先使用Sockets协议来进行录制，Microsoft .NET协议就留着以后再深入了解吧。
第一步：录制脚本。没什么可说的，一步步操作即可。
第二步：回放脚本
回放的过程中发现脚本回放的很慢，一个脚本在忽略think time的情况下回放竟然需要好几分钟，但事务的响应时间并不长。本以为在generator慢，在controller下会快一些，结果试了一下还是一样。
仔细查看回放log后发现在回放慢的事务中都包含了很长的wasted time，这就是回放慢的原因了。查找资料后才知道是由于录制时接收buffer的大小与回放时接收的buffer大小不同（Mismatch）产生的。LR中当遇到Mismatch时，会重新读取socket中的数据，直到超时为止。这个超时时间默认为10秒，可使用lrs_set_recv_timeout2函数进行修改。当脚本回放时mismatch很多时，自然就慢了，而且这个时间并不计入响应时间，而是计入wasted time。
修改了一些返回长度固定的buffer size，又把lrs_set_recv_timeout2设为5秒后，脚本回放时间大大缩短了&#
最低0.47元/天 解锁文章
3537
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
