gpt4 book ai didi

BizTalk 单例编排实例已被淹没

转载 作者:行者123 更新时间:2023-12-04 05:36:08 24 4
gpt4 key购买 nike

我们有一个单例(顺序车队)编排实例,它被大约 14000 条消息淹没。这意味着该实例已经处理了 8 天,但处理速度目前非常缓慢(大约每 7 分钟 1 个)。该实例启动速度很快,但在过去几天中已放缓至当前的性能水平。

我们已经从这个实例中转移了更多的消息,我们的计划是在它通过积压完成处理后终止它。

问题是,根据我们计算出的当前处理率,我们还有三天时间才能完成(大约还有 660 条消息需要处理)。

我的问题是:有什么办法可以加快速度吗?

最佳答案

我们设法为此创建了一个解决方法:

  • 查询消息框并检索所有已消费但未处理的消息
  • 杀死运行缓慢的编排实例
  • 将所有未处理的消息通过管道返回,在其中创建了一个新的编排实例。

  • 这个新实例不受前一个实例的所有历史记录(消耗的消息)的影响,因此运行速度提高了大约 60 倍,快速清除了剩余的积压。

    我们识别已消费但未处理的消息的方式是使用我在此处记录的方法: Technique for knowing the number of consumed but unprocessed messages for a given BizTalk sequential convoy orchestration instance

    其余的,一旦您从 messagebox 数据库中检索了消息 guid 列表,就会在以下位置进行记录:
  • How to retrieve Message Body from BizTalk Database
  • 3 ways of programmatically extracting a message body from the BizTalk tracking database (我用的是第三个)

  • 总之,一旦您拥有消息 ID,您就可以从 messagebox 数据库中的 Parts 表中选择 imgPart 列,这将为您提供消息正文的二进制编码压缩版本。然后,您可以使用上述文章中的代码来重构消息。

    在此之后,它只是获取所有消息,然后通过 MSMQ 接收位置将它们重新发送回 biztalk 的情况。

    从长远来看,我们将需要解决导致此问题发生的设计中的缺陷 - 尽管预计不会发生洪水,但在重载下使运行过程的性能在地板上坍塌绝不是一个好地方。

    我们遇到的问题是,对于我们的大多数消费者系统,必须维护源消息排序。出于这个原因,我们到处都有单例,所有这些都可能面临这个问题。

    我已经发布了关于消息 re-sequencing BizTalk 中的策略在这里: Resequencing strategies for ordered delivery in BizTalk

    关于BizTalk 单例编排实例已被淹没,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11904447/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com