我遇到了一个慢速（自定义）BizTalk适配器的问题。
每晚，应用程序会在几分钟内向MSMQ发送超过10'000条消息。 不幸的是，BizTalk需要几个小时来处理它们。
我没有任何编排，只是将消息路由到多方。 对于一方，我们必须开发一个自定义适配器，但这个适配器/接口非常慢。 所以我认为BizTalk会自动限制整个应用程序，并且只从队列中读取可以通过这个慢速适配器发送的尽可能多的消息。
因此，在MSMQ为空之前需要几个小时。
如果我停止这个慢速适配器，例如只启用写入本地文件系统的文件适配器，处理来自MSMQ的数千条消息需要几秒钟。
是否可以调整BizTalk以更快地处理传入的消息，并仅限制此发送端口的传出消息？不幸的是，由于一个缓慢的聚会，所有其他方都必须等待这些消息。
感谢您的任何建议！
祝你好运 迈克尔
答案 0 :(得分：1)
我可以想到一种可能有助于解决问题的架构方法，特别是考虑到您的评论：
是否可以调整BizTalk以更快地处理传入的消息，并仅限制此发送端口的传出消息？ 不幸的是，所有其他方都因为一个缓慢的聚会而不得不等待这些消息。
对于每一方，创建一个新的MSMQ'聚会队列'并从传入（大消息卷）队列直接写入该队列 - 一个具有多个'聚会'发送端口的接收端口/位置订阅传入消息和写入他们各自的'党排队'。
您现在可以从每个“聚会队列”中读取并使用相关的发送端口（如果需要，使用慢速适配器）发送消息 - 这应该比使用单个发送端口快得多;你实际上将接收方从发送方解耦。
我还会考虑检查您的主机/主机实例策略，以确保您从投票的角度进行适当的分离。