BizTalk单例业务流程实例已被淹没

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

我们已经从这个实例转移了更多的消息，我们的计划是一旦它完成了对积压工作的处理，就终止它

问题是，根据我们计算出的当前处理率，距离完成还有三天（大约660条消息需要处理）

---

我的问题是：我们有没有办法加快这一进程

我们注意到了与我们最初的单态/多态模式类似的行为。原因似乎是因为有太多消息与业务流程“相关”，即使消息已完成处理，也无法可靠地从messagebox中删除，因为业务流程实例仍在运行（BTS 2009，无SP）。一旦spool表达到约500k行，所有主机都进入节流状态（我认为是6），然后吞吐量急剧降低

以下是有帮助的：

我们确保我们的消息和变量在orch中被严格限定范围，一旦不再需要它们，就会导致它们超出范围

我们添加了一个超时，以允许多音在一段不活动时间（例如60秒）后“消失”。这样做的缺点是，如果新消息在兽人死亡时到达，那么可能会导致僵尸。幸运的是，我们能够让我们的合作伙伴以突发方式发送消息，中间有延迟，从而避免了这个问题

---

如果您发现您的服务器由于messagebox/spool表级别而处于节流状态，您可以做的是临时增加“”，例如增加系数10，然后重新启动主机-这可能会清除当前积压

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

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

查询messagebox并检索所有已使用但未处理的消息

杀死执行缓慢的业务流程实例

将创建业务流程新实例的所有未处理的消息通过管道传回 这个新实例不受前一个实例的所有历史记录（消耗的消息）的影响，因此运行速度快了大约60倍，快速清除了剩余的积压工作

我们识别已消费但未处理的消息的方法是使用我在此处记录的方法：

其余部分，一旦从messagebox数据库检索到消息GUID列表，将在以下位置记录：

• （我用了第三个）

总之，获得消息ID后，您可以从messagebox db中的Parts表中选择imgPart列，这将为您提供消息正文的二进制编码压缩版本。然后使用上述文章中的代码重新构建消息

在此之后，只需获取所有消息，然后通过MSMQ接收位置将它们重新发送回biztalk

从长远来看，我们需要解决导致这一问题发生的设计缺陷——尽管没有预料到洪水，但在重载情况下，让运行过程的性能在地板上坍塌永远不是一个好地方

我们面临的问题是，对于我们的大多数用户系统，必须维护源消息顺序。因此，我们到处都有单身汉，他们都有可能面临这个问题

---

我在此处发布了BizTalk中的消息策略：

谢谢您的帮助-问题似乎正如您所说的-此实例的消息消耗量很大。我检查了假脱机表计数器，以及所有节流状态计数器，但没有任何节流，假脱机表只有30K，所以不太大。我现在正在记录一个变通程序，一旦我们在生产中进行了更改，将在这里发布。谢谢，是的，它们都在运行。我已经发布了解决此问题的方法，谢谢您提供的信息。出于兴趣，还有第四种方法-存储过程ops_LoadTrackedPartFragment可用于重新组装来自MsgBoxDb或DtaDb的消息片段（由BtsAdmin MMC跟踪消息UI使用）。通过在Tracking_Parts1（UIDPPartId）中添加SQL索引，尤其是在邮件积压变得可怕的情况下，您可以极大地加快搜索速度，尤其是在DtaDb中。感谢您的添加@nonnb下次将尝试这样做-听起来麻烦少多了