LoadRunner超时问题和错误

LoadRunner 是以客户端的角度来定义“响应时间”的，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果，设置步长则可以缓解这一情况，这样，应该试试设置pacing，再运行看看情况。

在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。
　　错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

　　错误分析：对于HTTP协议，默认的超时时间是120秒(可以在LoadRunner中修改)，客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

　　错误现象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

　　错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

　　解决办法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器，最好对其性能进行优化。

　　如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

　　最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout”或者“HTTP-request receive”的值。

 

执行测试并分析调优：

　　测试中报错的信息解决：

　　1. Failed to connect to server "域名:80": [10065] No Route to Host

　　解决：

　　这种错误信息有两种情况，一是交换机堵塞，一是服务器网络堵塞或者CPU无法响应（网卡中断处理不过来了）。

　　从服务器端检查下iptables 是否开启，看看 /proc/sys/net/ipv4/ip_conntrack_max 是多少。

　　2. TTP Status-Code=500 (Internal Server Error)

　　解决：

　　A． 这个问题，开发人员从程序和环境进行调优了。

　　B． 通过抓包发现有大量的sql语句重复执行，建议优化sql。

　　C． 优化JVM。机器配置：4G的内存，32个线程并发能力

　　-Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

　　3. HTTP Status-Code=504 (Gateway Time-out)

　　解决：

　　502 bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。

　　504Gateway Timeout 由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。

　　解决：可以启动多个tomcat服务，一个tomcat服务可能支撑不了那么大的并发。（一般情况下像IBM高配的服务一个tomcat能支持2000并发吧。）（只能让部署环境的同事帮忙调整，我们没这权利啊。）

　　4. Step download timeout (120 seconds) has expired when downloading non-resource(s)

　　解决：

　　可以修改配置参数（tomcat的），也可以程序上进行调整超时时间。

　　如 <Connector port="8080"

　　maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

　　enableLookups="false" redirectPort="8443" acceptCount="100"

　　debug="0" connectionTimeout="20000"

　　disableUploadTimeout="true" />

　　当然了也可以调整LR的配置但最好不这样。

　　5. Abnormal termination, caused by mdrv process termination

　　解决：

　　大胆尝试了修改了LR中的D:\Program Files\Mercury\LoadRunner\dat\protocols 中的http.lrp信息，在[Vugen]下面新加一条MaxThreadPerProcess=要设置的vuser数量 。

　　测试结果：

　　● 前台发帖：

　　场景设计：执行2000并发匿名对不同的区发帖，每15秒上50个用户，2000个用户全部到达后，持续执行10分钟。

并发数提问响应时间成功率%服务器每秒处理的请求数吞吐量（Mbps）2000    

　　● 后台回帖：

　　场景设计：执行400并发对同一区不同的帖子进行回复，每10秒上20用户，400个用户全部到达后，持续执行10分钟。

并发数回帖响应时间成功率%服务器每秒处理的请求数吞吐量（Mbps）400    

　　注：响应时间的单位为：秒

　　这个测试结果比较满意，还在进一步调优。

http://www.51testing.com/html/96/n-131696.html

还有一种解释是这样的

我在托管机房用LR11测试NGNIX搭建得WEB时，出现Action.c(22): Continuing after Error -26610: HTTP Status-Code=502 (Bad Gateway) for“http://xxxx.com”问题，
解决思路：1允许同一IP模拟大量用户并发发送请求；
2每个用户用一个IP地址对服务器加压；
3服务器安全设置，像防洪水攻击等等，需要从防火墙、操作系统的配置文件设置；
最后我的问题解决方法是：同一个IP拟模大量用户并发，LINUX服务器的安全设置中像防洪水设置就把它当做攻击。查出问题原因后，取消此安全设置，解决了HTTP Status-Code=502 (Bad Gateway) 错误。