背景:
被测系统是一个使用.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秒后,脚本回放时间大大缩短了&#