BizTalk Server 2006 / R2 节流机制

BizTalk 2006 / R2 在性能和节流机制方面提供了一些很好的改进，如果您密切负责 BizTalk 环境或任何消息传递系统的管理和性能调优工作，那么您就可以直观地理解在任何消息传递系统中，提取（pick）处理时间场景的复杂性。本文我将重点介绍 BizTalk 中特定的节流场景及其解决方案。我通过参考几本书籍以及我在 BizTalk 环境性能标准方面的个人经验，整理了以下内容。
以下场景可能无法涵盖实际 BizTalk 环境中所有可能的节流情况，但我已尽力从记忆中收集了尽可能多的内容。

场景：消息传递速率/完成速率的消息比率较高

比率值偏高表明服务无法处理进入该环境的入站/入站消息的速率。解决方案是节流消息传递，为 XLANG 和出站传输等 BizTalk Server 组件提供尽可能多的资源。结果是消息完成率、消息延迟率和消息框的 IO 操作率将呈指数级降低，清理出站端点的队列也能带来更多好处。
理想情况下，环境应将比率值保持在 1.05 – 1.07 左右。
我们可以通过 WMI / OM 对象 / Perfmon 计数器等各种工具来监控消息传递速率和消息完成速率。

场景：请求速率/完成速率的发布比率较高

高比率表明消息框无法应对负载。为了改善这种情况，我们可以在环境中阻止发布线程以减慢速率，也可以指示服务类减慢消息发布速率。在这种情况下，除了扩展消息框所在的 SQL Server 环境之外，没有其他解决方案。如果环境同时面临这些问题，那么扩展 SQL Server 环境将是一个恰当的决定。
我没有关于比率值的准确观察结果，但我确信每个组织都需要 1 才能称得上可靠的消息传递服务 :-)。
要获取比率值，我们需要监控提交批处理（commit batch）调用的进入和退出。

场景：进程内存超过阈值

如果进程内存超过阈值，那么您的环境和批处理过程可能需要大量内存。如果您经常收到此类警报或消息，则应考虑为环境增加内存。在这种情况下，它会影响 XLANG 和所有类型的传输（适配器/管道）等组件。这也表明服务需要进行脱水（dehydrate）和收缩（shrink）缓存。
通过监控进程的私有字节（private bytes），我们可以清楚地了解各个进程的内存阈值。在 BizTalk 中，主机可以被视为进程。

场景：系统内存超过阈值

我们可以假设与上面“进程内存超过阈值”的场景相同的可能性。
您可以在此处通过 perfmon 监控物理内存及其趋势。

场景：进程使用的数据库会话超过阈值计数

您可以在 BizTalk 环境中节流发布。为了改善这种情况，我们需要正确调优 SQL Server 数据库，并根据我们的阈值要求进行纵向扩展/横向扩展。在这种情况下，XLANG 和所有入站传输都会受到影响。对此场景没有快速的解决方案，但我们可以减少/阻止 SQL Server 上外部/空闲的会话。如果 BAM 通知 / BAS 已配置到您的环境中，并且它们的数据库也在同一台服务器上运行，那么您可以禁用/暂停那些优先级较低的服务以恢复消息处理到正常状态。
这种情况会影响 XLANG 对象以及所有类型的入站传输。
您可以通过 Perfmon 计数器 / SQL Server 计数器 / Management Studio 等来监控消息框上的会话。对于集群环境，您可以监控每个消息框的会话。

场景：进程线程数超过特定阈值

节流发布、传递，这表明需要减小线程池大小。
这种情况会影响 XLANG 对象以及所有类型的传输（适配器 / 管道）。该场景没有直接的解决方案，长期解决方案可能是横向扩展服务器，并建议迁移到 64x 或 Itanium（或同等）处理器服务器。为了处理白天某些高峰处理时间，我们可以为处理阈值的主机进程提供更多的线程和优先级。
您可以监控每个 CPU 的线程数等计数器来应对此类场景/情况。

BizTalk Server 2006 / R2 会自动处理此类节流，但通过对机制给予一些优势，我们可以获得更好的性能。为了执行自动节流，BizTalk Server 使用配置参数。我将在下一篇文章中对每个参数进行详细回顾。
感谢您在阅读本文时容忍我。您的宝贵反馈和建议欢迎发送至 nilayparikh@gmail.com。
请访问我的博客 http://biztalk-ssis-ssas.blogspot.com/。