由lrs_create_socket问题引起对LoadRunner/Rational Robot请求内容的探索

ppent

发现问题的应用场景
  C/S结构程序，请求响应采用异步机制。即客户端发送一个请求后不是一直等待这个结果，客户端将请求存放在请求队列并获得一个JOBID，服务器运行后将运行结果存放在响应队列，客户端定时查看响应队列，根据JOBID定时从响应队列中获取结果。因此带来的测试问题是受服务器状态影响，客户端获取结果的次数不固定。
测试脚本示例
  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是循环去获取结果并检查返回的标志位，若仍没有结果返回则在一定时间后循环获取结果，因此请求数不固定。
LR提示socket异常
  当我用lrs_create_socket创建连接之后，当这个socket连接的请求次数达到100次后，这个连接就不可用了，必须close后再重新create。LoadRunner提示错误：Error : socket0 - Software caused connection abort. Error code : 10053.
问题验证
  一开始认为是LoadRunner对Socket的支持问题，因为同样的测试方式在Rational Robot中可以通过。于是做了最简单的一个试验：
  1、用socket方式录制访问某个网页并保存（如baidu、或tomcat的默认页面）
  2、添加循环方式去访问
  结果证明在socket请求次数达到100后即无法再次访问了（少数次数可以达到一百零几）。
  
  脚本如下：
  #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;
  }
  
  LoadRunner VUGen日志如下：
  ...
  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.
新的发现
  在发现以上问题后百思不得其解之后即和一些测试朋友进行讨论交流，但同样没有什么头绪。在一次交流中意外发现朋友的测试脚本中连接的是80端口，于是推断他是用IIS作为测试服务器，突然意识到这是否和应用服务器也有关，立即采用IIS作为服务器进行测试，居然测试通过了，并没有出现Socket连接问题！随后用Weblogic进行测试也同样通过！
初步结论
  由以上的各种验证方法发现问题并非单独由LoadRunner引起的，而是和测试的应用服务器也有很大关系。仅当用LoadRunner测试Jboss、Tomcat服务器时才会出现这种问题，而对IIS、Weblogic等问题并不存在。但另有一个奇怪的问题是采用Rational Robot用同样的测试方法，所有的服务器类型都没有问题！
继续探索
  后来进一步研究为何同样的采用tomcat服务器，在请求上有什么不同差异导致了两种测试工具决然不同的测试结果。但通过Charles工具只是发现了一些请求上的细微差异，并不会造成此问题的发生。于是此疑案悬而未决，希望有志之士加入一起研究，共同探索其中奥秘！

zhengaiqi

求解决方法。。怎么处理10053错误。。

youer511

为啥把create、close放在action里面，也会报10053的错？还有9002的错

yaya_free

我也遇到类似的问题，我在用LR测试一个C/S结构时，录制脚本时总出现socket2 - Software caused connection abort. Error code : 10053.的错误，就因为有这个错误，使得我在设置完Scenario后运行，全部失败，无法继续进行我的测试，请高手指点，谢谢

ppent

你的问题发生的原因和我的并不一样。
你的问题说的不是很详细。你测试的web系统是否使用了cookie？在测试执行时第一次没有出错，而在进行迭代时出现该错误？
初步估计，你的问题估计是和LoadRunner的场景设置有关。你可以看看你的场景的Rumtime setting中，是否选中了“simulate a new user on iteration”选项？该设置会在每次迭代时清除上下文。
将该选项去掉再试试。

Zee

sdlkfj3 sdlkfj3 sdlkfj3

mihan

最近测WEB B/S结构的系统时，如果多次循环查询会抛 STATUS-CODE =400 这个错误，WEB_什么_file函数总是请求失败，显示什么网页NOT FOUND，但LR单用户或2用户跑多次却不会出现该问题，WEB服务器也已叫专家调优，不知出现的问题是否和这篇文章的情况有异曲同工之妙，查了许多资料都查找不到，网上对于STATUS-CODE =400 NOT FOUND这个错误解决办法好象也是很多，说明很多情况下都会抛这个错误。我想我可以试下调这个参数，说不定可以解决，不知楼主是否遇到过STATUS-CODE =400这个错误

ppent

最后，感谢和我一起交流、思考、尝试的Zee，没有他的帮助我很难独自解决该问题，也感谢给我作出解答使我得到启发的段念老师。
通过这件事情，我们又有什么收获呢？思考中。。。

ppent

进一步探索Tomcat服务器、LoadRunner对lrs_create_socket问题的事情经过。
起始
一开始觉得可能是测试脚本或LoadRunner测试工具的兼容性问题，于是开始在这方面找原因。
在与Zee的交流过程中，Zee以其丰富的经验和敏锐的直觉发现了一个一直以来被我忽略的现象，即在每次Socket Error之前，其前一个Receive Buffer总是Mismatch，那么，是否由于这个Mismatch导致了下一个Socket请求的错误，或者说，两者有什么必然性？

发展
在对测试脚本多次检查之后，没发现测试脚本有什么问题，但就是每次出错前总有一个Mismatch Buffer。在进一步的分析中发现，测试脚本中只建立了一个Socket连接，对同一个页面重复多次的发出相同的请求，有点类似Dos的攻击方式，是否服务器认为这些数据包是恶意攻击而拒绝了我的请求造成的呢？上次关河也是如此的答复。嗯，这个很有可能。但是，如果是服务器的安全策略的话，为何Robot进行同样的操作，为何又没有问题呢？因为Robot并不需要直接去Create Socket，而只需要通过Http_Request建立连接即可，是否两者在底层的实现上有所不同？事情变得扑朔迷离，好像难以继续下去了。
下午，Zee决定自己搭一个环境试试看。

高潮
下午Zee自己搭建了一个Tomcat环境，但在录制脚本时出现了一个奇怪的问题。用Winsock协议，Internet Application方式进行录制时，居然有事件，但就是录不到脚本！没办法，只好将我的脚本给他。在他的环境中，问题还是重现了。出错时服务器也没有任何的log可以供参考，这样问题的定位变得很困难。就在我们都无计可施，认为就是服务器的安全策略时，事情又有了新的转机。
如果真是服务器的安全策略的话，网上应该有所介绍，那么到网上去找找相关信息。在查找的过程中突然发现了一些关于HTTP的信息，具体如下：
KeepAlive On
在HTTP 1.0中，一次连接只能作传输一次HTTP请求，而KeepAlive参数用于支持HTTP 1.1版本的一次连接、多次传输功能，这样就可以在一次连接中传递多个HTTP请求。虽然只有较新的浏览器才支持这个功能，但还是打开使用这个选项。

MaxKeepAliveRequests 100
MaxKeepAliveRequests为一次连接可以进行的HTTP请求的最大请求次数。将其值设为0将支持在一次连接内进行无限次的传输请求。事实上没有客户程序在一次连接中请求太多的页面，通常达不到这个上限就完成连接了。

KeepAliveTimeout 15
KeepAliveTimeout测试一次连接中的多次请求传输之间的时间，如果服务器  已经完成了一次请求，但一直没有接收到客户程序的下一次请求，在间隔超过了  这个参数设置的值之后，服务器就断开连接。  

这个信息象一根救命稻草一样，一下子被我们紧紧捉住，然后就是赶紧查资料看这个参数在哪里设置的。接下来的故事情节相信大家都已经猜到了，在对服务器配置文件进行了MaxKeepAliveRequests参数设置后，测试脚本请求次数顺利突破了原有的极限，问题都得到了解决！

尾声
到此为止，问题基本上已经明确。由于Apache服务器在HTTP 1.1协议的处理策略，需要进行KeepAlive的参数设置，而默认的MaxKeepAliveRequests只有100的请求限制，于是就出现了问题出现的那一幕。
剩下的疑问和推断是：
1. 既然原来的Tomcat服务器默认的MaxKeepAliveRequests只有100，而Rational Robot又可以无限制的进行访问请求，则上面提到的问题似乎可以推测出来：Raional Robot在Socket连接处理上并不只是用一个连接，否则由于服务器的限制会有同样的问题。
2. 通过采用HTTP 1.1标准的不同应用服务器，如IIS、Weblogic并不存在该限制问题，以上的参数是否仅对相关服务器（Apache、Tomcat、JBoss）有效？

[ 本帖最后由 ppent 于 2007-3-10 14:05 编辑 ]

ppent

这个问题已经发现了有好长一段时间，但一直未能发现其中的问题所在。
后来用http监视工具对比LoadRunner和Robot两者http请求也没发现很大的差异，因此不得而终。希望有zee的帮助能解决这个问题。

Zee

路过。来看看。