Loadrunner Sockets协议实战问题总结

背景：
被测系统是一个使用.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秒后，脚本回放时间大大缩短了，但有些数是据根据请求不同动态返回的，肯定会出现mismatch，暂时就没辙了，不过后面会说到解决办法。

第三步：增强脚本
参数化没什么特殊的，不再多说了，要注意的一点就是把原始值替换为参数时，有些数据中间有换行，容易遗漏。

这里主要说说动态关联。

Sockets协议中有3个用于关联的函数，分别是lrs_save_param、lrs_save