Action.c(28): Error -27796: Failed to connect to server "xxxx": [10060] Connection timed out

Error -27796: Failed to connect to server "125.93.51.230:8080": [10061]

Connection refused..

2013.05.31,这个27796一直是我心中的痛，试过网上所有的方法了，还是不行，我只能怀疑是不是我的客户端OS是win7的，所以才造成这种情况.....哎~！

认真分析这个错误，其实比较容易理解，就是连接不上服务，由于端口已经满了，那么自己的本机已经修改成65534，服务器已经修成成65534，那么这就是唯一的解决方式么？后来仔细思考，我找到了两种解决方式：

1、通过让每次迭代不启用新的连接，我想就可以解决此问题，经过验证，发现这个问题确实不发生了。操作如下，在controller的运行时设置中的-->browser Emulation-->不扣选simulate a new user on each iteration，这样运行时并发人数是多少，那么就启动多少个端口。还是上面的问题，是否勾选这个选项就一定会报27796错误么？

2、回答上面的提问，答案是不一定。如果你每次迭代启用新的端口，但是由于迭代次数*并发数<65534就不会报这个错误。如果设置的迭代次数*并发数>65534，也不一定会出现这个错误，例如：并发人数为1000,平均响应时间为1s，那么也就是说1s会占用1000个端口，也就是说不到66s时端口就会占满，如果服务器能在65s内关闭之前占用的端口之间的连接，也就是说65s超时时间，或者会话保持为65s以内，那么就能解决此问题。

以上提出两种解决方式，都可以解决27796error，一个是修改loadrunner中的controller设置，另一个就是设置服务器的超时时间在合理范围之内，不要太长，也不要太短。

Action.c(58): Error -27796: Failed to connect to server "www.baidu.com:80": [10048] Address already in use
Try changing the registry value
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay to 30
and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\MaxUserPort to 65534
and rebooting the machine
See the readme.doc file for more information

.......2012.10.20.-----

网上的提示多为：LR压力测试遇到如上错误，跟据提示在注册表中已将TcpTimedWaitDelay  改为 1;MaxUserPort 改为 65534；并且重启电脑。运行后仍出现上面的错误。。。。但还是无法解决。

于是~~~~：
在 run-time setting/browser emulation中将simulate a new user on each iteration  选项去掉（默认是选中的）。重新运行一切正常，没有错误出现。

【复制博主的猜测：
猜测原因，客户端性能比较好，发出压力太快，所以把tcp/ip的连接或端口占满。在网上查了一下，xp好像默认开启15个tcp/ip。。。

去掉这个选项的意思是，始终使用一个tcp/ip链接，不断开，也就是开发人员所说的长链接或持久连接。   
短连接：建立连接-----发送和接收报文1-------关闭连接

长连接：建立连接-----发送和接收报文1.。。。2.。。。3-----关闭连接 】

问题描述：

使用http协议，200VU并发访问：URL=http://124.74.192.111/xx.web.taobao/pages/left.jsp，测试中正常，但URL增加了端口号8080即：URL=http://124.74.192.111:8080/xx.web.taobao/pages/left.jsp,并设置了持续时间，开始运行controller即开始报大量的错：“Action.c(5): Error -27796: Failed to connect to server "124.74.192.111:8080": [10048] Address already in use
Try changing the registry value
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/tcpip/Parameters/TcpTimedWaitDelay to 30 and HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/tcpip/Parameters/MaxUserPort to 65534 and rebooting the machine”。

问题解决：

根据错误提示，修改测试机设置：HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/tcpip/Parameters/TcpTimedWaitDelay其值改小，比如5. 重启测试机，再加压测试即可。

根据提示还要调整“MaxUserPort ”的键值，因为这里的测试机该值已为最大，故不需要调整这个值 。

分析：

借用zee的分析思路：因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后，就会出现上面的错误。执行netstat –na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了。

因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后，就会出现上面的错误。执行netstat–na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了。

成功的解决方法：

 

在负载生成器的注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值：

TcpTimedWaitDelay

MaxUserPort

1,这里的TcpTimedWaitDelay默认值应该中是30s，所以这里，把这个值调小为5s（按需要调整）。

2,也可以把MaxUserPort调大（如果这个值不是最大值的话）。
==========================================================================================

Action.c(28): Error -27796: Failed to connect to server "router.pay.360buy.com:80": [10060] Connection timed out

1. 修改压力机注册

尝试修改注册表中 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值： TcpTimedWaitDelay  --- 1 MaxUserPort  ----  65534 端口等待时间调小，最大可用端口调大

二. 在nginx 和 tomcat所在服务器上查看连接数是不是已满, 输入

   netstat -an | grep TIME_WAIT -wc   发现大约有19000个

看来确实有很多time_wait的连接啊!

1. 检查 /ext/sysctl.conf ,是不是有

net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1

这两项配置,发现已经配置了

2. 修改loadrunner的配置

分别修改VUGEN和 control 二者的run time setting中的请求超时时间Preferences 中点击Options 其中有三项的参数可以一次都修改了，

HTTP-request connect timeout              建议修改为1000

HTTP-request receieve timeout             建议修改为1000

Step download timeout                            建议修改为10000

Http Keep Alive time out                            建议修改800

 

 

 

 

1. 修改压力机注册

尝试修改注册表中
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值：
TcpTimedWaitDelay  --- 1
MaxUserPort  ----  65534
端口等待时间调小，最大可用端口调大

二. 在nginx 和 tomcat所在服务器上查看连接数是不是已满, 输入

   netstat -an | grep TIME_WAIT -wc   发现大约有19000个

看来确实有很多time_wait的连接啊!

1. 检查 /ext/sysctl.conf ,是不是有

net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_tw_reuse = 1

这两项配置,发现已经配置了

2. 修改loadrunner的配置

分别修改VUGEN和 control 二者的run time setting中的请求超时时间Preferences 中点击Options 其中有三项的参数可以一次都修改了，

HTTP-request connect timeout              建议修改为1000

HTTP-request receieve timeout             建议修改为1000

Step download timeout                            建议修改为10000

Http Keep Alive time out                            建议修改800

转载：http://blog.csdn.net/on_my_way20xx/article/details/8646108

 

 

http://www.51testing.com/html/21/562021-869112.html

 

 

 

在性能测试过程中，大家都可能遇到过LR-27796错误，此类错误屡见不鲜..在走访了各大论坛后，发现大侠们给出的各类的版本的27796错误，那么27796是如何产生的呢？接下来跟大家分享下我的所得与感想

在测试一个web站的接口项目中，出现了大量的27796错误（此报错代码有很多种错误提示，比如：27796—Failed to connect toserver、27796—timeout、27796-No Route To Host等），根据LR的帮助提示是修改注册表的两个键值后方可解决，我试着修噶了注册表，重启了机器，在喜气冲冲的进行新的一轮压测过程中发现，错误木有解决，依然存在27796错误。我开始在网上搜索此问题的处理办法，说法云云：1、重启机器、2、修改注册表、3、更换操作系统（囧）我发现对我木有效果，出现错误的请求占总请求的20%左右，这个比例压测是无任何意义的！心灰意冷....

我开始从第一个27796—Failed to connect to server开始查找原因，如果出现连接失败，肯定是客户端与服务器端的通信出现了问题导致的，不论外界原因，实质就是通信!
我试着使用网络工具wireshark在LoadRunner开启时，抓取通信信息。问题出现了，在监测通讯过程中发现，问题出现在第二次握手，客户端已经发出syn包，但服务器端没有接受到syn包，
当timewait三秒钟后再次发出syn包，服务器端可以接收到此包，问题出现了，就是说这个请求在没有建立连接时就出现错误了，神奇了！！！
客户端与服务器端
建立连接如下：
第一次　　第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。第二次　　第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 
　　

三次握手

第三次　　第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

问题找到原因了，那么这些不同的27796有那些问题，如何产生的呢？

答案1：大家可能有手工编写脚本的习惯，大家使用最多的协议应该是web/http协议，那么GET、POST请求是最常见的，例如：web_url("www.baidu.com",                 "URL=http://www.baidu.com", 
                "Resource=0", 
                "RecContentType=text/html", 
                "Referer=", 
                "Snapshot=t2.inf", 
                "Mode=HTML", 
                LAST);
这段代码中我们来分析下，如果把以上代码修改为
     web_url("www.baidu.com",                 "URL=http://www.baidu.com",
                LAST);
请 求是否成功？答案是肯定是，可以发起get请求。那么大家实验过没有如果这样的话，在压测过程中是否出现过问题？LR会出现27796错误，大家可以实验 下，那么问题出在那呢？问题就出现在自己的代码中，缺少RecContentType=text/html类型导致GET请求出现问题，服务器端无法识别 请求携带的标示，所以自己的代码编写是27796产生的一部分

原因2：这个是摘自百度的 帖子"因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占 满后，就会出现上面的错误。执行netstat –na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了"
说白了点，就是端口没有释放掉timeout状态，没有恢复到监听的状态，所以此时做好的办法就是，重启电脑恢复这些端口占用的状态，当重启机器后，查看状态netsat -nao 后，如果恢复到正常端口的状态，就可以再次进行性能测试了。

原因3：第三个原因
在 性能测试i过程中，可能出现服务器资源利用率过高，导致建立连接失败现象，此类错误应该查看服务器的资源利用率，如果出现了资源利用过高现象，27796 的错误也会在此时产生！27796的错误一般都是由于建立连接失败而导致的，建立连接失败的原因有很多种情况，大家只要明白其中27796的产生错误的实 质就可以了，在大家测试过程中欢迎大家跟帖，在什么情况出现的这种错误，如何解决的继续下去！

 

 

 

http://www.360doc.com/content/10/0805/09/1429048_43780321.shtml

 

 

 

3.http协议是怎么保持长连接的。在HTTP首部的Connection: Keep-alive中，Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。max=XXX，表示这个长连接最多接收XXX次请求就断开。如果在客户端，即发请求的时候，没有定义超时时间。服务端也会发起四次挥手的。TCP还有心跳检查机制来当前连接是否活着。TCP的keep alive和HTTP的Keep-alive的区别。TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。TCP keep alive的表现：当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。HTTP的Keep-alive中的Keep-alive：timeout =20就是TCP通道保持20秒。

 

 

HTTP的长连接和短连接

本文总结&分享网络编程中涉及的长连接、短连接概念。

关键字：Keep-Alive，并发连接数限制，TCP，HTTP

一、什么是长连接

HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

　HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端-->代理-->服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端-->代理”连接和“代理-->服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多，很多时候代理是我们自己控制的，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理，常见的是客户端跟Nginx代理服务器使用HTTP1.1协议&长连接，而Nginx代理服务器跟后端服务器使用HTTP1.0协议&短连接。

在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection: Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。

以前使用libcurl做的上传/下载，就是短连接，抓包可以看到：1、每一条TCP通道只有一个POST；2、在数据传输完毕可以看到四次握手包。只要不调用curl_easy_cleanup，curl的handle就可能一直有效，可复用。这里说可能，因为连接是双方的，如果服务器那边关掉了，那么我客户端这边保留着也不能实现长连接。

如果是使用windows的WinHTTP库，则在POST/GET数据的时候，虽然我关闭了句柄，但这时候TCP连接并不会立即关闭，而是等一小会儿，这时候是WinHTTP库底层支持了跟Keep-alive所需要的功能：即便没有Keep-alive，WinHTTP库也可能会加上这种TCP通道复用的功能，而其它的网络库像libcurl则不会这么做。以前观察过WinHTTP库不会及时断开TCP连接。

二、长连接的过期时间

客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：

上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

三、长连接的数据传输完成识别

使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。更细节的介绍可以看这篇文章。

四、并发连接数的数量限制

在web开发中需要关注浏览器并发连接的数量，RFC文档说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩，知乎这里有分析，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。

五、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive

TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。

TCP keep alive的表现：

当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。

这个“一段时间”可以设置。

WinHttp库的设置：

WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.

libcurl的设置：

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html

CURLOPT_TCP_KEEPALIVE

Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).

CURLOPT_TCP_KEEPIDLE

Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT_TCP_KEEPINTVL

Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT_TCP_KEEPIDLE是空闲多久发送一个心跳包，CURLOPT_TCP_KEEPINTVL是心跳包间隔多久发一个。

打开网页抓包，发送心跳包和关闭连接如下：

从上图可以看到，大概过了44秒，客户端发出了心跳包，服务器及时回应，本TCP连接继续保持。到了空闲60秒的时候，服务器主动发起FIN包，断开连接。

六、HTTP 流水线技术

使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指，在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining。

由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决）。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样。

在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源。

目前浏览器并不太重视这个技术，毕竟性能提升有限。

查看某个端口的连接数

windows 2003查看80端口方法

在cmd命令提示符上输入netstat -an |find /c ":80"

出来的数字应该就是连接数

linux 连接数查看外部 如何查80端口

统计80端口连接数

netstat -nat|grep -i "80"|wc -l

2）统计httpd协议连接数

ps -ef|grep httpd|wc -l
---------------------
作者：boshuzhang
来源：CSDN
原文：https://blog.csdn.net/boshuzhang/article/details/51942650
版权声明：本文为博主原创文章，转载请附上博文链接！

 

 

 

解决方法：

1.采用多个conctoller 压力机

2.修改服务器端http连接，keep_alive 超时时间时间缩短

 

 

3.调整中间件连接池，增加连接池

4.修改jvm参数。增大jvm 参数 

 

 

一、        Action.c(11): Error -27796: Failed to connect to server问题处理

loadrunner运行报下面的错误:

Action.c(11): Error -27796: Failed to connect to server "sz.pupuwang.com:80"

解决办法：

1、修改注册表：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay to 30
and
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\MaxUserPort
to 65534

2、 运行时间哪里设置去掉2个勾选项目

3、场景设置：tools  -----option 设置连接超时时间
，360秒，默认是120秒

3、下载安装一个TCP/IP连接数修改软件，将windows默认的10个连接改大，1000-2000

最后解决办法，关闭nginx  防火墙