WCF双工第一次回调慢(NetTcpBinding) [英] WCF Duplex First Callback SLOW (NetTcpBinding)

问题描述

我们正在使用 非常 使用NetTcpBinding的简单自托管服务，它们都在同一台计算机上(当前，但是在两台不同的计算机上也进行了测试).

客户端类的CallbackBehavior设置为ConcurrencyMode.Multiple，UseSynchronizationContext设置为false.

Duplex客户端调用该服务.在该服务中，我们使用OperationContext.Current.GetCallbackChannel将接口代理返回到客户端.该接口代理已存储.

15到60秒(或任何其他时间)之后，服务会使用ThreadPool.QueueUserWorkItem调用回调代理，以实际进行回调.在服务器端，我看到回调函数立即启动.

但是，回调在大约10到15秒内未击中客户端！

随后到客户端的回调不会发生可检测的延迟.

在第一个回调期间，根据TaskManager(CPU使用率的1-4％)，CPU并没有做任何耗时的工作.

当客户端位于远程计算机上时，TCP流量不会出现大的峰值(根据WireShark).

我确实意识到，进行第一个呼叫可能需要一些内部设置.但是十秒以上吗???休息一下！这些是计算机，而不是赛鸽！

减速速度不受CPU限制.它不受网络限制.到底是什么导致了令人惊讶的性能下降?

甚至更奇怪的是，如果客户端不使用回调而是为回调托管一个服务，并仅向该服务提供要调用的地址/端口，则该调用会立即进行而不会造成任何延迟.您可能会认为这会比较慢. 在双工情况下(至少对于net.tcp而言)，您会认为它们已经打开了可用于回调的套接字，并且回调实际上会更快.显然不是.

这使得在我们的应用程序中几乎无法使用双工回调.虽然我们不需要微秒的回调，但需要10到15秒！

Microsoft的任何人都曾经测试过这些东西吗?

 

解决方案

嗨肯，

您从客户端调用的WCF方法以及回调方法应具有属性< OperationContract(IsOneWay:= True)>在您的服务合同中.

此致

Prabi

We are using a very simple self hosted service using NetTcpBinding, all on the same machine (currently, but tested on two different machines as well).

The client class has a CallbackBehavior set to ConcurrencyMode.Multiple, UseSynchronizationContext set to false.

The Duplex client makes a call into the service.  In the service we use OperationContext.Current.GetCallbackChannel to get the interface proxy back to the client.  This interface proxy is stored.

After 15 - 60 seconds (or whatever) the service makes a call into the callback proxy using ThreadPool.QueueUserWorkItem to actually make the callback.  On the server side I see that the callback function is started immediately. 

However, the callback does not hit the client for about 10 to 15 seconds!

Subsequent callbacks into the client happen with no detectable delay.

The CPU isn't doing anything time consuming according to TaskManager (1 - 4% CPU usage) during this first callback.

When the client is on a remote machine there is no huge spike in tcp traffic (according to WireShark).

I do realize that there may be some internal setup required to make that first call.  But 10+ seconds???? Give me a break!  These are computers, not carrier pigeons!

The slowdown isn't CPU bound.  It isn't network bound.  What the heck is causing the absurdly slow performance?

What's even stranger is that if instead of using callbacks the client hosts a service for the callback and simply provides the service with an address/port to call into, the calls happen without any delays.  You would think that this would be slower.  In the duplex case (at least for net.tcp) you would think that they would already have a socket open that could be used for the callback, and that a callback would actually be faster.  Apparently not.

This makes using a duplex callback virtually unusable for our applications.  While we don't need a microsecond callback, 10 - 15 seconds!

Has anybody at Microsoft ever tested this stuff?

 

解决方案

Hi Ken,

The WCF method that you calling from the client as well as the callback method should have attribute <OperationContract(IsOneWay:=True)> in your service contract.

Regards,

Prabi

这篇关于WCF双工第一次回调慢(NetTcpBinding)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！