问WCF超时异常详细调查

EN

我们有一个应用程序，它有一个运行在IIS7上的WCF服务(*.svc)，以及查询该服务的各种客户端。服务器正在运行Win 2008 Server。客户端运行的是Windows 2008 server或Windows 2003 Server。我得到了以下异常，我所看到的实际上可能与大量潜在的WCF问题有关。

System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. 

我已将超时时间增加到30分钟，但仍出现错误。这告诉我还有其他因素在起作用，因为上传或下载的数据量永远不会花30分钟。

错误来来去去。目前，这种情况更加频繁。如果我有3个客户端同时运行或100个客户端同时运行，这似乎并不重要，它仍然偶尔发生一次。大多数时候，没有超时，但我每小时仍然会有几次。该错误来自所调用的任何方法。其中一个方法没有参数，并返回一些数据。另一个接受大量数据作为参数，但异步执行。错误始终来自客户端，并且从不在堆栈跟踪中引用服务器上的任何代码。它总是以：

 at System.Net.HttpWebRequest.GetResponse()
  at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

在服务器上:我已经尝试(并且目前有)以下绑定设置：

maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"

它似乎没有什么影响。

我已经尝试(并且目前拥有)以下限制设置：

<serviceThrottling maxConcurrentCalls="1500"   maxConcurrentInstances="1500"    maxConcurrentSessions="1500"/>

它似乎没有什么影响。

我目前对WCF服务有以下设置。

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]

我用ConcurrencyMode.Multiple运行了一段时间，错误仍然出现。

我尝试过重新启动IIS，重新启动底层SQL Server，重新启动机器。所有这些似乎都不会产生影响。

我已尝试禁用Windows防火墙。它似乎没有什么影响。

在客户端上，我有以下设置：

maxReceivedMessageSize="2147483647"

<system.net>
    <connectionManagement>
    <add address="*" maxconnection="16"/>
</connectionManagement> 
</system.net>

我的客户端关闭其连接：

var client = new MyClient();

try
{
    return client.GetConfigurationOptions();
}
finally
{
    client.Close();
}

我已更改注册表设置以允许更多传出连接：

MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.

我最近刚刚尝试过SvcTraceViewer.exe。我设法在客户端捕获了一个异常。我看到它的持续时间是1分钟。查看服务器端跟踪，我可以看到服务器并没有意识到这个异常。我能看到的最大持续时间是10秒。

我已经在服务器上查看了使用exec sp_who的活动数据库连接。我只有几个(2-3)。我已经使用TCPview查看了来自一个客户端的TCP连接。它通常在2-3左右，我已经看到了5到6个。

简单地说，我被难住了。我已经尝试了我能找到的一切，一定是遗漏了一些非常简单的东西，WCF专家将能够看到。我的直觉是，在服务器实际接收消息之前，有什么东西在低层(TCP)阻塞了我的客户端，和/或有什么东西在服务器层将消息排入队列，而从不让它们处理。

如果您有任何我应该查看的性能计数器，请让我知道。(请指出哪些值是错误的，因为其中一些计数器很难解码)。另外，我如何记录WCF消息大小？最后，有没有什么工具可以让我测试我可以在客户端和服务器之间建立多少连接(独立于我的应用程序)

耽误您时间，实在对不起!

6月20日添加的额外信息：

我的WCF应用程序执行类似下面的操作。

while (true)
{
   Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
   Step2GetWorkUnitFromServerViaWCF();
   DoWorkLocally(); // takes 5-15minutes. 
   Step3SendBackResultsToServerViaWCF();
}

使用WireShark，我确实看到当错误发生时，我有五次TCP重新传输，随后是TCP重置。我的猜测是RST来自WCF，正在终止连接。我收到的异常报告来自Step3超时。

我通过查看tcp流"tcp.stream eq192“发现了这一点。然后我将我的过滤器扩展到“http eq192和tcp.stream eq POST”，并在此期间看到了6个帖子。这看起来很奇怪，所以我检查了另一个流，比如tcp.stream eq 100。我有三个帖子，这看起来更正常，因为我在做三个电话。但是，我确实会在每次WCF调用后关闭连接，因此我希望每个流都有一个调用(但我对TCP了解不多)。

进一步研究后，我将http数据包负载转储到磁盘上，以查看这六个数据包在哪里调用。

1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2

我的猜测是两个并发客户端正在使用相同的连接，这就是为什么我看到重复的原因。然而，我仍然有几个我不能理解的问题：

a)为什么报文损坏？随机网络--也许吧？使用以下示例代码对加载进行this压缩：http://msdn.microsoft.com/en-us/library/ms751458.aspx -当并发使用时，代码会偶尔出现错误吗？我应该在没有gzip库的情况下进行测试。

b)为什么在损坏的操作超时后，我会看到步骤1和步骤2正在运行？在我看来，这些操作似乎不应该发生。也许我没有看到正确的流，因为我对TCP的理解有缺陷。我还有其他同时出现的流。我应该调查其他流--快速浏览一下流190-194，就会发现Step3 POST有正确的有效负载数据(没有损坏)。让我再看一遍gzip库。