我有一个WPF客户端通过以下方式请求数据WCF服务托管于IIS 7。服务方法调用存储过程（SQL 2012) using EF检索一些数据。
由于需要加载大量数据，因此客户端会多次调用服务方法，以“分解”数据加载并避免大量负载和超时。
我们使用生成的服务代理，这些代理扩展自System.ServiceModel.ClientBase<T>.
我们还使用带有二进制编码的自定义 http 绑定（来自here http://architects.dzone.com/articles/wcf-over-https-compression-and) - 实际实现如下所示：
<customBinding>
<binding name="CustomBinding_IPointDataAccess" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00">
<binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" maxSessionSize="2048">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="16384" />
</binaryMessageEncoding>
<httpTransport manualAddressing="false" maxBufferPoolSize="524288"
maxReceivedMessageSize="2147483647" allowCookies="false" authenticationScheme="Anonymous" bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" maxBufferSize="2147483647" proxyAuthenticationScheme="Anonymous" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" />
</binding>
此外，IIS 中还启用了动态压缩。我可以在 Fiddler 中查看请求，并且消息正文的大小很好（~50KB）并且99% 的请求会在一两秒内返回。完美的！
然而，几乎每次迭代中，都有一个调用需要几分钟才能完成，我不知道为什么......我的sendTimeOut客户端上的时间是1分钟，自然一个调用就会失败。我将其延长到 10 分钟，通话似乎在 2 分钟多一点的时间内完成 - 尽管有时需要更长的时间。该问题看起来非常随机 - 可能是第一个调用，也可能是第 30 个调用。但它的可重复性很强。
我在 WCF 服务方法中的存储过程调用周围放置了一些日志记录，它在一秒钟内执行并获取数据。所以，我认为这不是数据库问题。
使用 Fiddler，有问题的调用会生成类似于以下内容的输出：
ACTUAL PERFORMANCE
--------------
ClientConnected: 14:02:42.959
ClientBeginRequest: 14:03:01.224
GotRequestHeaders: 14:03:01.224
ClientDoneRequest: 14:03:01.574
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 46ms
HTTPS Handshake: 0ms
ServerConnected: 14:05:16.021
FiddlerBeginRequest: 14:05:16.021
ServerGotRequest: 14:05:16.021
ServerBeginResponse: 14:03:04.784
GotResponseHeaders: 14:05:16.561
ServerDoneResponse: 14:05:16.611
ClientBeginResponse: 14:05:16.611
ClientDoneResponse: 14:05:16.611
注意之间的重要时间ServerBeginResponse and GotResponseHeaders。这似乎与所看到的问题惊人相似here https://stackoverflow.com/questions/14872999/understanding-fiddler-statistics.
我启用了 WCF 服务跟踪，快速浏览了一下，没有错误或警告，但除了基础知识之外，我无法真正理解我所看到的内容。
我怎样才能确定问题所在？是序列化吗？是网络问题吗？服务器跟不上客户端发送这么多请求吗？
我尝试通过添加适当的内容来调整配置文件中的 WCF 限制serviceBehaviors，但这并没有什么区别。
我应该提到的是，我是通过 VPN 连接执行此操作的，但文件传输、远程桌面连接等其他操作也可以正常工作。看来还是蛮靠谱的。
如有必要，我可以提供更多详细信息。
编辑（2013 年 10 月 6 日）：不确定这是否相关或只是侥幸，但有几次，我注意到在有问题的调用中，主体大小明显小于其他调用。并非每次都是如此，但它可能会提供一些线索。这是 Fiddler 的屏幕截图，向您展示每次调用时 Body 大小应保持一致。所选条目 (#21) 比其他条目小得多，但需要 2 分钟以上才能完成。
奇怪的是，这次我收到了异常。异常并非每次都会发生。
System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
