gpt4 book ai didi

.net - WCF - 进行多次调用时随机客户端超时

转载 作者:可可西里 更新时间:2023-11-01 15:12:14 27 4
gpt4 key购买 nike

我有一个 WPF客户端通过 WCF 请求数据服务托管于 IIS 7 .服务方法使用 SQL 2012 调用存储过程 ( EF )检索一些数据。

有大量数据要加载,因此客户端多次调用服务方法以“中断”数据加载并避免大量有效负载和超时。

我们使用从 System.ServiceModel.ClientBase<T>. 扩展的生成的服务代理

我们还使用了带有二进制编码的自定义 http 绑定(bind)(来自 here)- 此处显示的实际实现:

<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 之间的重要时间和 GotResponseHeaders .这似乎与看到的问题惊人地相似 here .

我启用了 WCF 服务跟踪,快速浏览了一下,没有错误或警告,但除了基础知识之外,我无法真正理解我所看到的内容。

我怎样才能确定问题出在哪里?是连载吗?是网络问题吗?服务器跟不上客户端发送这么多请求吗?

我尝试通过添加适当的 serviceBehaviors 来调整配置文件中的 WCF 限制, 但这并没有什么不同。

我应该提一下,我是通过 VPN 连接执行此操作的,但文件传输、远程桌面连接等其他操作都可以正常工作。看起来还蛮靠谱的。

如有必要,我可以提供更多详细信息。

编辑 (6.10.2013): 不确定这是相关的还是侥幸,但有几次,我注意到在有问题的调用中,主体大小明显小于其他。并非每次都是这样,但它可能会提供一些线索。这是 Fiddler 的屏幕截图,向您展示 Body 大小应该与每次调用保持一致的程度。所选条目 (#21) 的大小比其他条目小得多,但需要 2 分钟多的时间才能完成。

enter image description here

奇怪的是,这次我收到了一个异常。异常不会每次都发生。

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)

最佳答案

正如我在评论中建议的那样,请尝试将传输模式设置为流式传输以排除这是与内存压力相关的问题的可能性(因为流式模式应该会导致 wcf 使用更少的内存)。

当我看到这个问题时怀疑这可能是问题所在,因为它似乎只发生在您快速连续调用许多服务电话时。根据我的经验,这通常是以下两个问题之一:代理未从客户端正确关闭,或者服务器由于内存压力正在运行 GC。

当传输模式被缓冲时,WCF 将消息响应的整个数据集加载到内存中,然后再将其发送回客户端。 Streamed 只是将数据发回而无需缓冲。对于大型数据集,它往往要快得多,对于小型数据集则稍慢,并且总是使用更少的内存(在服务器和客户端上)。

关于.net - WCF - 进行多次调用时随机客户端超时,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16991398/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com