6

我遇到了慢速（自定义）BizTalk 适配器的问题。

每天晚上，应用程序会在几分钟内向 MSMQ 发送超过 10,000 条消息。不幸的是，BizTalk 需要几个小时来处理它们。

我没有任何编排，只是将消息路由到多方。对于一方，我们必须开发一个自定义适配器，但是这个适配器/接口非常慢。所以我认为 BizTalk 会自动限制整个应用程序，并且只从队列中读取它可以通过这个慢速适配器发送的尽可能多的消息。

因此，MSMQ 为空需要数小时。

如果我停止这个慢速适配器，例如只启用一个写入本地文件系统的文件适配器，则需要几秒钟来处理来自 MSMQ 的数千条消息。

是否可以调整 BizTalk 以更快地处理传入消息并仅限制此发送端口的传出消息？不幸的是，所有其他方都必须等待消息，因为一方速度慢。

感谢您的任何建议！

最好的问候迈克尔

4

2 回答 2

6

您可能会遇到基于速率的限制条件（请参阅 MSDN）。当Publishing Rate（消息进来的速度）超过Delivery Rate * Rate Overdrive Factor（发送的消息率 * 限制百分比）时，就会发生这种情况。

避免这种限制状态的一种简单方法是在 BizTalk 主机配置设置中增加您的速率过载因子。这可能不是最佳实践，因为听起来您需要将 Rate Overdrive Factor 设置为非常高的值，这可能会产生其他影响。

根据您构建解决方案的方式，您的另一种选择是将您的发送端口/适配器拆分到其自己的主机实例上。由于限制是在每个主机实例的基础上执行的，因此拆分此特定适配器的处理意味着它将不再影响通过标准适配器功能传递给其他方的消息的性能。

于 2012-09-18T22:36:24.437 回答
1

我可以想到一种可以帮助您解决问题的架构方法，特别是考虑到您的评论：

是否可以调整 BizTalk 以更快地处理传入消息并仅限制此发送端口的传出消息？不幸的是，所有其他方都必须等待消息，因为一方速度慢。

对于每一方，创建一个新的 MSMQ“方队列”并从传入（大消息量）队列直接写入该队列 - 单个接收端口/位置，多个“方”发送端口订阅传入消息并写入各自的'派对队列'。

您现在可以读取每个单独的“派对队列”并使用关联的发送端口（如果需要，使用慢速适配器）发送消息 - 这应该比使用单个发送端口快得多；您实际上将接收端与发送端分离。

我还会考虑审查您的主机/主机实例策略，以确保您从节流的角度进行适当的分离。

于 2012-10-03T10:22:26.077 回答