我有一个使用两种方式 WCF-BasicHttp 发送端口调用 WCF 服务的编排。出于测试目的，我的 WCF 服务只接受一个参数，并返回一个值，因此我知道它没有任何耗时的逻辑。事实上，使用 WCFTestClient 客户端工具，我知道 WCF 服务调用只需几毫秒。
当我在编排中调用 WCF 服务时，发送形状大约需要 7 秒左右，而接收形状大约相同。因此，例如，在我的编排中花费的时间可能是 15 秒，而 wcf 服务的发送和接收形状占据了其中的 90 多秒。
我唯一能想到的是我主机上的轮询设置不正常。我有 3 台主机，1 台用于发送端口，1 台用于接收端口，1 台用于编排。每个都配置有默认配置。
此外，我对发送端口的打开、发送和关闭超时设置分别为 5,4 和 3 秒。这两个操作都没有超时，我相信问题不在于 wcf 服务本身，而在于 BizTalk 或我的 BizTalk 解决方案。
在下图中，请注意 sndGetDemographics 和 recGetDemographicsResponse 每个都需要大约 7 秒才能完成：
我发现了我的问题。因为其他各种组件在事件日志中写入的内容相当冗长，所以我之前没有注意到这一点，但 BizTalk 似乎正在限制我的一些主机实例（我有 3 个，一个用于接收，一个用于发送，一个用于编排）作为其他东西的副作用。
发生的情况是，出于测试目的，我有一个使用文件适配器的发送端口，将收到的消息输出到目录。随着文件数量的增长，文件系统变得非常缓慢，导致发送端口实例需要很长时间，并且在某些情况下会暂停。这导致消息框变大。BizTalk 看到了增长并决定限制主机实例，以便它以较慢的速度发布消息，这解释了为什么 wcf 服务调用的发送和接收形状需要很长时间。
在本课中，我学到了很多关于 BizTalk 节流的知识！此外，在发送端口上使用文件适配器时要非常小心和有争议。
在我看来，你的管道是罪魁祸首。如果您使用的是 XMLTransmit/XMLReceive，请尝试转向 PassThruTransmit 和 PassThruReceive 管道。
在我看来是这样，因为发送端口的 Receive 事件在时间方面是完美的，只有 Send 事件需要很长时间。
只是为了确定：您没有使用任何特殊的 WCF 行为/检查器？