loadrunner_LR中错误代号为27796的一个解决方法（转载）

原文见：http://blog.csdn.net/zeeslo

问题：

曾经遇到过一个问题，在一次性能测试过程中，使用http协议的多用户向服务器发送请求。设置了持续时间，出现错误为：27796, Failed to connect to server 'hostname';port_ld': 'reason'.10048.（凭记忆写的，不知道写错了没有）

分析:

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

官方的troubleshooting：
查看工具的troubleshooting，如下：

均不是解决之道。

成功的解决方法：

在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值：
TcpTimedWaitDelay
MaxUserPort
1,这里的TcpTimedWaitDelay默认值应该中是30s，所以这里，把这个值调小为5s（按需要调整）。
2,也可以把MaxUserPort调大 --> 65534 （如果这个值不是最大值的话）。

反复验证，问题解决。

 

看图片：

 

 

 

 

真实太谢谢zee了，这种无私贴最喜欢了

===============================================================================

xp系统问题 error -27792,-27796等问题，都是和xp系统的tcp连接数有限制导致，默认是10，修改下这个默认值为150或者250，基本上就可以解决了。 修改tcp连接数，网上有很多方法，我用的是最偷懒的方法，就是装一个bit精灵，里面有“tcp连接数破解补丁”，设置下就好了

=====================================================================================

TcpTimedWaitDelay和MaxUserPort设置
描述：确定 TCP/IP 可释放已关闭连接并重用其资源前，必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期（2MSL）状态。此时间期间，重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接，为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接，而且由于 TIME_WAIT 中存在很多连接，导致低吞吐量，则调整此参数。 如何查看或设置： 使用 regedit 命令访问 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 注册表子键并创建名为 TcpTimedWaitDelay 的新 REG_DWORD 值。 将此值设置为十进制 30，其为十六进制 0x0000001e。该值将等待时间设置为 30 秒。 停止并重新启动系统。 缺省值：0xF0，它将等待时间设置为 240 秒（4 分钟）。 建议值：最小值为 0x1E，它将等待时间设置为 30 秒。 MaxUserPort 描述：确定在应用程序从系统请求可用用户端口时，TCP/IP 可指定的最高端口号。 如何查看或设置： 使用 regedit 命令访问 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 注册表子键并创建名为 MaxUserPort 的新 REG_DWORD 值。 停止并重新启动系统。 缺省值：无 建议值：至少十进制 32768。 注：当在 Windows NT 或 Windows 2000 操作系统上
调整 WebSphere Application Server 时，同时使用这两个参数。希望本站的知识能给您的工作、学习和生活带来方便和乐趣！  

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tuwen/archive/2008/03/17/2191742.aspx

关于Windows频繁打开关闭端口时出现的问题

最近事情很多，人也懒，东西看了不少，也想到过一些东西，但就是懒得写。现在记录一下前两个星期做一个压力测试时出现的现象，希望重开一个好头。简单地说，这是个从Windows Server连接Linux下的MongoDB服务时出现的问题。MongoDB使用的是自定义的二进制协议，客户端使用普通的TCP连接进行连接后再读写数据。在以前的测试中，我使用的都是建立少量连接，每个连接进行多次操作，而这次则是对“应用程序”进行压力测试，因此需要不断地开启及关闭连接——频率大约是每秒4、500次吧。

我使用的环境是Windows Web Server 2008 R2，MongoDB部署在Cent OS上，双方都是64位操作系统。压力测试刚开启时一切顺利，性能也比较令人满意，但是不久后便会抛出这样的异常：

由于系统缓冲区空间不足或队列已满，不能执行套接字上的操作。

一开始我以为是程序里有哪个地方没有释放连接，于是检查了程序代码，觉得没有问题；后来又直接使用mongodb-csharp进行频繁连接关闭，结果还是出现了同样的错误，于是我又怀疑是驱动本身的问题，但是看了看讨论组中似乎又没有人汇报过这个问题；于是我又换了个思路，使用了Java平台上的驱动写了个简单的测试程序，居然还是得到了这个错误。由此我确定了两点：

• 这很可能不是mongodb-csharp这个驱动程序的问题。当然，要确定这一点还需要更多测试，例如在mono上使用这个驱动。
• 这是操作系统方面的问题，因为.NET和Java都给出了同样的错误信息，甚至和当前程序的语言文化设置无关。

还有一个细节：在直接使用驱动进行插入操作的时候，发现无论使用多少线程同时进行，最终永远是在插入了16370-16380条记录之后停止，这意味着每次都是打开关闭了确定次数之后出现的错误，这很有可能是一个操作系统限制所致的结果。因此，我使用这段错误信息在网上寻找解决方案，原因有很多，大都不是我需要的。顺便一提，只有中文的错误信息真是很难找到合适的结果，因此我不得不通过几个关键字，再连蒙带猜地得到了错误的标准英文翻译：

An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.

有了这段信息，找起答案来就简单多了，例如KB上找到了这样一条记录，说是在Windows Vista及2008中，Tcp/IP动态端口的范围调整到49152至65535，做一个简单的减法可以发现我们可以使用16384个接口，和我们之前看到的记录数量大致相同，基本可以确定是频繁地打开关闭操作造成客户端的动态端口用尽的问题。KB上也给出了解决方法，只要使用netsh命令便可以进行设置。

不过有意思的是，我在此之前还找到了另一条记录，说是在HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下面可以增加一个MaxUserPort参数，指定程序可以使用的端口范围，它的默认值是5000，也就是端口范围是1025至5000，这也是上一条记录中说Windows之前的端口策略，它的“适用范围”已经不包括2008系统，但我鬼使神差地将MaxUserPort设置为65534（十进制）之后，原本只能插入16000多条记录的程序已经能够插入数万条，这意味着修改的确生效了。

当然，这么做还是没有解决问题，总不见得插入这么多条记录之后还是失败吧。其实第二条记录里还写到，有一个TcpTimedWaitDelay参数，表示一个关闭后的端口等待多久之后可以重新使用，顺着这个信息我找到了《TCP/IP Registry Values for Windows Server 2008》这样一篇文章，描述Vista与2008系统中各种TCP/IP相关的参数，其中自然包括了TcpTimedWaitDelay，它的默认值为120，表示端口关闭后120秒才能重新使用。

于是我们来算一下，假设有60000个端口可用，如果在120秒内消耗完毕，则每秒最多使用500个端口，这远远低于MongoDB的性能瓶颈，甚至接近了一个Web应用程序的需求——根据压力测试，我们单台Web服务器每秒可以处理接近200个动态请求，这意味着平均每个请求只能使用2.5个连接。根据文档，我将TcpTimedWaitDelay设成最短的30秒，这意味着我们可以每秒开启关闭2000个端口，平均每个请求使用10个连接。够了。

这个问题就这样解决了，说实话很简单，也就是个“知道就能解决”的配置问题。当然现在这个方式并不算太理想，更好的方式应该是利用连接池，这样便不会开启/关闭大量的TCP/IP连接，默认的端口数量也已经足够了，更重要的是这也可以省下很大的开销——因为经过测试，即使是最复杂的ASP.NET页面，只要不涉及MongoDB，每秒也能处理6500多个请求，而目前每秒200个动态请求，从数字上看也远低于MongoDB的能力，我们有理由相信目前的性能似乎是卡在连接的打开/关闭上了。

只可惜目前mongodb-csharp的连接池实现有bug，用于清理连接的维护进程居然会让造成明显的中断，甚至在频繁使用十几分钟后还抛出了异常。有机会的话我再看看吧，但我总觉得它目前的实现过于复杂了，我估计都可以说是面向对象的“经典”使用案例了。

最后再来一提，话说我目前使用的是64位的Windows Web Server 2008 R2系统，功能强大，价格便宜，授权宽松，最多允许使用到32GB内存，作为Web服务器我很满意。