BizTalk 低延迟 - 将 C# 调用到 WCF-Published-Orchestration 的响应时间问题

Question

从 C# 程序调用 WCF 发布的编排通常需要亚秒级的响应时间。但是，在某些情况下，在 C# 程序中的调用与来自编排的第一条跟踪消息之间可能需要 20-50 秒。运行调用 WCF 的 C# 在 HIS/HIP（主机集成服务/CICS 主机启动处理）下运行。

几乎每次我重新启动 HIS/HIP 服务时，我们的响应时间都很慢，因此 CICS 会超时。我还担心如果事情“变冷”，它可能会在白天发生 - 换句话说，也许事情正在被缓存。即使是 JIT 首次编译也不应该花费 20-50 秒吗？另一件看起来奇怪的事情是，缓慢的响应时间似乎是编排的负载，它在 BizTalk 服务下运行，而不是我循环的 HIP/服务。

担心的是，当我们上线时，早上的第一个用户（或在“冷咒”之后会超时）。他们在超时后第二次尝试，总是很快。

我通过重新启动以下各项进行了一些测试： 1) BizTalk 服务 2) IIS 3）HIS/HIP事务集成器（HIP服务）

重新启动其中任何一个往往会导致大约 20 秒的延迟。 重新启动所有 3 就像死亡之吻 - 大约有 60 秒的延迟，然后从编排中出现第一条痕迹。

即使重新启动 HIP 服务，HIP 程序也总是快速给出它的第一个跟踪。不知道为什么重新启动 HIP 会减慢编排的启动速度。

谢谢，

尼尔·沃尔特斯

Answer 1

我也看到了 MQSeries 适配器的这种行为。在一段时间不活动后，启用与 MQSeries 通信的 COM+ 组件将由于不活动而关闭。

我们有一个 10 分钟的计时器，它会强制发出某种保持活动的消息。我不知道您是否有可以发送的非破坏性呼叫，或者您是否可以为此目的在系统中构建一个。

Answer 2

我对需要在 2 秒内工作的 BizTalk 流有同样的问题，但是当它有一段时间未使用时，将 dll 重新加载到缓存中会产生超时。

我们在 MS 的 Orchestration Engine Configuration 文档中找到了解决方案，其中解释了如何避免卸载 dll：

使用AppDomainSpecs 中的SecondsIdleBeforeShutdown 和SecondsEmptyBeforeShutdown 选项并在ExactAssignmentRules 或PatternAssignmentRules 部分中分配所需的dll，您可以永久加载您的dll，也许您可​​以避免调用者应用程序.

请注意，如果您重新启动 BizTalk 主机，则会再次加载 dll。