BizTalk单例编排实例已被淹没

Question

我们有一个单身（顺序护送）编排实例，其中充斥着大约14000条消息。这意味着该实例已处理8天，但处理速度目前非常缓慢（大约每7分钟1次）。该实例开始很快，但在过去几天已经放慢到目前的性能水平。

我们已经转移了远离此实例的更多消息，我们的计划是在完成处理积压后终止它。

问题是，根据我们计算的当前处理速度，我们在完成之前有三天（大约有660条消息要处理）。

我的问题是：我们有什么方法可以加快速度吗？

Answer 1

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

1. 查询消息框并检索所有已消耗但未处理
的消息
2. 杀死效果缓慢的业务流程实例
3. 管理所有未处理的消息，其中创建了业务流程的新实例。

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

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

其余的，一旦您从消息框db中检索了消息guid列表，就会记录在以下位置：

• How to retrieve Message Body from BizTalk Database
• 3 ways of programmatically extracting a message body from the BizTalk tracking database（我使用了第3个）

总之，一旦有了消息ID，就可以从消息框db中的Parts表中选择imgPart列，这样就可以得到消息体的二进制编码压缩版本。然后，您可以使用上述文章中的代码重新构建消息。

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

从长远来看，我们需要解决我们的设计中导致出现这个问题的缺陷 - 虽然预计不会发生洪水，但是在重负荷下运行过程的性能会在地板上崩溃，这绝不是一个好地方。 。

我们遇到的问题是，对于我们的大多数消费者系统，必须保持源消息排序。出于这个原因，我们到处都有单身人士，所有人都可能遇到这个问题。

我在此处发布了有关BizTalk中消息re-sequencing的信息：Resequencing strategies for ordered delivery in BizTalk

Answer 2

我们注意到我们的初始单例/多重模式的类似行为。似乎原因是因为许多消息与业务流程“相关”，即使消息已经完成处理，它也不能可靠地从消息箱中删除，因为业务流程实例仍在运行（BTS 2009，没有SP）。一旦假脱机表达到约500k行，所有主机进入限制状态（我认为它是6），然后吞吐量急剧减慢。

以下有帮助：

1. 我们确保我们的消息和变量在orch中具有严格的范围，导致它们在不再需要时立即超出范围。
2. 我们添加了一个超时，以允许多段在一段时间不活动后“死亡”，例如60秒这样做的缺点是，如果新的消息在orch死亡时到来，那僵尸就会产生。幸运的是，我们能够让我们的合作伙伴以突发间隔发送消息，从而避免了这个问题。

如果您发现服务器因邮箱/假脱机表级别而受到限制，您可以暂时增加“Message Count Threshold in database”，例如通过因子10，然后重新启动主机 - 这可能会清除当前的积压。

Answer 3

确保BTS数据库作业已启动并正在运行，并且已正确配置。