BizTalk直接绑定发送端口触发速度慢

BizTalk直接绑定发送端口触发速度慢,biztalk,biztalk-2016,Biztalk,Biztalk 2016,我有一个应用了最新FP2的BizTalk 2016企业开发环境 我有一个绑定到WebHttp接收位置的“守门人”编排。这只是将传入的xml消息发布到名为“MvcFormsPort”的直接绑定端口。从这里开始,物理请求-响应端口调用WCF web服务,响应流回到编排,并返回到WebHttp接收位置的调用者 从功能上讲,这很好。但是,对于一个特定的服务器(集成测试),性能存在问题,这似乎取决于物理请求-响应端口唤醒消息已发布并已订阅的事实所需的时间。这可以在下面的屏幕抓图中看到。逻辑直接绑定端口“M

我有一个应用了最新FP2的BizTalk 2016企业开发环境

我有一个绑定到WebHttp接收位置的“守门人”编排。这只是将传入的xml消息发布到名为“MvcFormsPort”的直接绑定端口。从这里开始,物理请求-响应端口调用WCF web服务,响应流回到编排,并返回到WebHttp接收位置的调用者

从功能上讲,这很好。但是,对于一个特定的服务器(集成测试),性能存在问题,这似乎取决于物理请求-响应端口唤醒消息已发布并已订阅的事实所需的时间。这可以在下面的屏幕抓图中看到。逻辑直接绑定端口“MvcFormsPort”在11:43:47收到消息,但订阅物理发送端口直到11:44:02才收集该消息;15秒后

在我的dev-vm上,相同的过程端到端大约需要1.5秒

主机的轮询设置仍默认为500毫秒


你知道是什么导致了问题环境的延迟吗?

我的错!问题是问题服务器的SSO中缺少连接字符串。

15秒似乎太长了。确定没有人在摆弄主机轮询设置之类的东西吗?真的!主机轮询仍然是500msDo,我很好奇丢失的连接字符串会导致延迟,而不是彻底失败。在第二台计算机上重试?有一个从业务流程调用的帮助程序集,该业务流程尝试使用BAM API创建BAM条目。此操作超时,但随后继续。