WCF 超时异常详细调查
我们有一个具有 WCF 服务的应用程序(* 。Svc)运行在 IIS7和查询服务的各种客户机上。服务器正在运行 Win2008服务器。客户端正在运行 Windows2008Server 或 Windows2003服务器。我得到了下面的例外，我已经看到，实际上可能与大量潜在的周转基金问题有关。
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、重新启动底层 SQLServer、重新启动计算机。所有这些似乎都没有影响。
我试过关闭 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。
简单地说，我被难住了。我已经尝试了所有我能找到的东西，一定是遗漏了一些非常简单的东西，周转基金专家可以看到。我的直觉是，在服务器实际接收到消息之前，有什么东西在底层(TCP)阻塞了我的客户机，并且/或者有什么东西在服务器层将消息排队并且永远不让它们处理。
如果您有我需要查看的性能计数器，请告诉我。(请说明哪些值不好，因为其中一些计数器很难破译)。另外，如何记录 WCF 消息的大小？最后，是否有任何工具可以让我测试在我的客户端和服务器之间建立多少连接(独立于我的应用程序)
谢谢你抽出时间！
6月20日补充的额外信息:
我的 WCF 应用程序执行类似于下面的操作。
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
通过使用 WireShark，我确实看到当错误发生时，我有五个 TCP 重新传输，随后是 TCP 重置。我猜测 RST 是来自 WCF 中断连接。我得到的异常报告来自第3步超时。
我通过查看 tcp 流“ tcp.stream eq 192”发现了这一点。然后，我将过滤器扩展到“ tcp.stream eq 192和 http 和 http.request.method eq POST”，并在该流中看到了6个 POST。这看起来很奇怪，所以我使用另一个流，比如 tcp.stream eq 100进行检查。我有三个 POST，这似乎更正常，因为我正在做三个电话。但是，我在每次 WCF 调用后都会关闭连接，所以我希望每个流调用一次(但是我对 TCP 了解不多)。
进一步研究之后，我将 http 包负载转储到磁盘，以查看这六个调用的位置。
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
我猜测是两个并发客户端使用相同的连接，这就是为什么我看到了重复。然而，我还有一些问题无法理解:
A)为什么数据包损坏了？随机网络侥幸，也许？使用以下示例代码压缩加载: http://msdn.microsoft.com/en-us/library/ms751458.aspx-当并发使用时，代码偶尔会出错吗？我应该在不使用 gzip 库的情况下进行测试。
B)为什么我会看到步骤1和步骤2在损坏的操作超时后运行？在我看来，这些行动似乎不应该发生。也许我没有看到正确的流，因为我对 TCP 的理解是有缺陷的。我还有其他同时发生的流。我应该调查其他流-快速浏览流190-194表明，第3步 POST 有适当的有效载荷数据(没有损坏)。迫使我再次查看 gzip 库。
最佳答案