我们有一个应用程序，该应用程序具有在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，我确实看到错误发生时，我进行了5次TCP重传，随后进行了TCP重置。我的猜测是RST是来自WCF终止的连接。我收到的异常报告来自Step3超时。
我通过查看tcp流“ tcp.stream eq 192”发现了这一点。然后，我将过滤器扩展到“ tcp.stream eq 192以及http和http.request.method eq POST”，并在此流中看到了6个POST。这似乎很奇怪，所以我检查了另一个流，例如tcp.stream eq100。我有3个POST，这似乎更正常一些，因为我正在进行3个调用。但是，我确实在每个WCF调用之后都关闭了我的连接，所以我希望每个流一个调用（但是我对TCP不太了解）。
经过更多调查，我将http数据包负载转储到磁盘上，以查看这六个调用在哪里。
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2我的猜测是两个并发客户端正在使用相同的连接，这就是为什么我看到重复的原因。但是，我还有其他一些我无法理解的问题：
a）为什么数据包损坏了？随机网络fl幸-也许？使用以下示例代码将负载压缩：http : //msdn.microsoft.com/zh-cn/library/ms751458.aspx-并发使用时，该代码是否偶尔会出现错误？我应该在没有gzip库的情况下进行测试。
b）为什么在损坏的操作超时后仍可以运行步骤1和步骤2？在我看来，似乎不应该进行这些操作。也许因为我对TCP的理解存在缺陷，所以我没有找到正确的流。我还有其他同时出现的信息流。我应该研究其他流-快速浏览流190-194会显示Step3 POST具有适当的有效负载数据（未损坏）。促使我再次查看gzip库。