BizTalk 延迟形状是不是占用任何资源或对性能不利？

Posted 2023-02-15

【中文标题】BizTalk 延迟形状是不是占用任何资源或对性能不利？

【英文标题】：Is BizTalk Delay Shape holding any resources or bad for performance?BizTalk 延迟形状是否占用任何资源或对性能不利？

【发布时间】：2021-10-11 02:55:02

【问题描述】：

我有一个集成，我在其中迭代多个批次并将它们发送到 WCF 服务。 WCF 服务的开发人员已与我联系，并说他们无法按照我们发送给他们的速度处理批次。他们想知道我们是否可以在每批之间等待 10 分钟。

话虽如此，我想知道 BizTalk 延迟形状是否适合这种情况？我猜测延迟形状会使编排处于脱水状态，因此它不会保留来自其他进程的任何资源。它是否正确？有什么理由我不应该考虑使用延迟形状？也许性能问题或类似的东西？我知道延迟形状是为这种场景创建的，但我只找到 1-2 分钟的示例。 10分钟可以吗？在产生负面影响之前，OK 是否有任何限制？

很多问题，但我希望它们有意义。

【参考方案1】：

是的，BizTalk 非常擅长快速处理大量消息，而且您确实会遇到必须限制 BizTalk 的情况。

我相信延迟形状会创建一个计时器，然后在时间过去后恢复编排。

延迟形状本身不会造成任何负面影响。我见过延迟时间超过这个时间的编排没有问题。唯一的副作用是如果你导致有很多脱水的实例，但我说的是超过 10K 的脱水编排。听起来你有某种单例模式，所以这可能不是问题。

【讨论】：

是的，我使用的是单例模式，所以这应该不是问题。但是脱水是如何工作的，它是否将线程和所有资源释放给其他进程，直到需要恢复？还是它持有资源，即锁定线程？

脱水通过将其持久化到数据库中来工作，所以不会，它不会阻塞任何资源。

好的，我明白了。感谢大侠的帮助，非常感谢！