我们有一个单例（顺序护航）编排实例，其中充斥着大约 14000 条消息。这意味着该实例已经处理了 8 天，但处理速度目前非常慢（大约每 7 分钟 1 次）。该实例启动速度很快，但在过去几天中已减慢到当前的性能水平。
我们已经从这个实例中转移了更多的消息，我们的计划是在它完成积压的处理后终止它。
问题是，根据我们计算出的当前处理速度，我们还有三天的时间来处理（大约还有 660 条消息需要处理）。
我的问题是：有什么办法可以加快速度吗？
问问题
2630 次
3 回答
2
我们设法为此创建了一个解决方法：
- 查询消息框并检索所有已消费但未处理的消息
- 杀死执行缓慢的编排实例
- 将所有未处理的消息通过管道返回，在这些消息中创建了一个新的编排实例。
这个新实例不受前一个实例的所有历史记录（消费消息）的影响，因此运行速度提高了大约 60 倍，快速清除了剩余的积压。
我们识别已消费但未处理的消息的方法是使用我在此处记录的方法：了解给定 BizTalk 顺序护航编排实例的已消费但未处理消息的数量的技术
其余的，一旦您从消息框数据库中检索到消息 guid 列表，就会记录在以下位置：
- 如何从 BizTalk 数据库中检索消息正文
- 从 BizTalk 跟踪数据库中以编程方式提取消息正文的 3 种方法（我使用了第 3 种方法）
总之，一旦您拥有消息 ID，您就可以从 messagebox db 的 Parts 表中选择 imgPart 列，这将为您提供消息正文的二进制编码压缩版本。然后，您可以使用上述文章中的代码来重建消息。
在此之后，它只是获取所有消息然后通过 MSMQ 接收位置将它们发射回 biztalk 的情况。
从长远来看，我们将需要解决导致此问题发生的设计缺陷 - 尽管没有预料到会发生洪水，但在重负载下让运行过程的性能崩溃通过地板从来都不是一个好地方。
我们遇到的问题是，对于我们的大多数消费者系统，必须维护源消息顺序。出于这个原因，我们到处都有单例，所有这些都可能面临这个问题。
我在这里发布了有关 BizTalk 中的消息重新排序策略的信息：Resequencing strategy for ordered delivery in BizTalk
于 2012-08-14T08:28:15.423 回答
1
我们注意到我们最初的单例/多例模式有类似的行为。原因似乎是因为太多消息与编排“相关”，即使消息已完成处理，它也不能可靠地从消息框中删除，因为编排实例仍在运行（BTS 2009，没有 SP）。一旦假脱机表达到约 500k 行，所有主机都进入限制状态（我认为是 6），然后吞吐量急剧下降。
以下帮助：
- 我们确保我们的消息和变量在 orch 中的范围很窄，一旦不再需要它们就会超出范围。
- 我们添加了一个超时，以允许多吨在一段时间不活动后“死亡”，例如 60 秒。这样做的缺点是，如果在管弦乐死亡时有新消息到达，可能会导致僵尸。幸运的是，我们能够让我们的合作伙伴突发发送消息，中间有延迟，从而避免了这个问题。
如果您发现您的服务器由于消息框/假脱机表级别而受到限制，您可以做的是暂时将“数据库中的消息计数阈值”增加10 倍，然后重新启动主机 - 这可能会清除当前的积压。
于 2012-08-11T13:02:59.157 回答
0
确保 BTS 数据库作业已启动并正在运行，并且已正确配置。
于 2012-08-13T20:27:23.937 回答