BizTalk 2010 WCF-BasicHTTP SendPort需要很长时间

Question

我有一个使用双向WCF-BasicHttp发送端口调用WCF服务的业务流程。出于测试目的，我的WCF服务只接受一个参数，并返回一个值，所以我知道它没有任何耗时的逻辑。事实上，使用WCFTestClient客户端工具，我知道WCF服务调用只需几毫秒。

当我在我的业务流程中调用WCF服务时，发送形状大约需要7秒左右，接收形状大致相同。因此，在我的业务流程中花费的时间可能是15秒，而wcf服务的发送和接收形状占用了90多个。

我唯一能想到的是我的主机上的轮询设置是不正常的。我有3个主机，1个用于发送端口，1个用于接收端口，1个用于编排。每个都配置了默认配置。

此外，我的发送端口的打开，发送和关闭超时设置分别为5,4和3秒。这两个操作都没有超时，我确信问题不在于wcf服务本身，而是在BizTalk或我的BizTalk解决方案中。

在下面的图片中，注意sndGetDemographics和recGetDemographicsResponse每个大约需要7秒钟才能完成：

Answer 1

我发现了我的问题。因为各种其他组件在事件日志中写得相当冗长，我之前没有注意到这一点，但看起来BizTalk正在限制我的一些主机实例（我有3个，一个用于接收，一个用于发送，一个用于编排）作为其他方面的影响。

出于测试目的，我发生了一个使用文件适配器的发送端口，将收到的消息输出到目录。随着文件数量的增长，文件系统变得非常缓慢，导致发送端口实例需要很长时间，并在某些情况下暂停。这导致消息框增长。 BizTalk看到了增长并决定对主机实例进行限制，以便以较慢的速率发布消息，这就解释了为什么wcf服务调用的发送和接收形状需要很长时间。

我在本课学到了相当多关于BizTalk限制的知识！此外，在发送端口上使用文件适配器时要非常小心和有争议。

Answer 2

对我来说，你的管道应该受到责备。 如果您正在使用XMLTransmit / XMLReceive，请尝试转向PassThruTransmit＆amp; PassThruReceive管道。

它在我看来是因为发送端口的Receive事件在时序方面是完美的，只有Send事件需要很长时间。

只是为了确定：您没有使用任何特殊的WCF行为/检查员？