可承受性能概述

在规划和评估系统可持续性时，从长远角度考虑可持续性至关重要。 主要注意事项包括：

• 加载配置文件和性能目标：当涉及到负载配置文件和性能目标时，不能有太多的详细信息。 测试和就绪性认证将基于能够长期处理这些负载。

• 争用服务器资源的其他活动和进程：这不仅仅是关于消息负载。 服务器上正在发生影响性能的其他进程和活动，例如数据库维护和 MessageBox 查询。

• 计划内和计划外系统中断和停机时间：Floodgate 事件和消息积压工作可能会更改有效的负载配置文件。

  在考虑构建可持续系统以及认证这些系统的测试时，请务必考虑这些因素并为其制定计划。

性能是否可持续？

在讨论BizTalk Server的性能时，我们定义最大可持续性能，如下所示：

• 系统可以在生产环境中无限期处理的最大消息流量负载。

  虽然这看起来很简单，但在评估解决方案（在一组特定硬件上运行）是否能够支持将解决方案投入生产后日复一日经历的负载时，必须考虑许多因素。

  在将解决方案投入生产前，请考虑以下因素以评估该解决方案是否可无限制处理最高消息通信负载：

• 预期的性能目标和吞吐量/延迟状况。

• 在同一硬件上运行的其他进程，例如：

  • 常规监视和故障排除

  • 操作数据库维护，例如日志传送、备份、清除、索引维护和统计信息更新。

  • 其他应用程序

• 计划内和计划外的系统停用，例如：

  • 合作伙伴站点中断，阻止发送或接收消息

  • 常规系统维护停机时间

了解您的性能目标

您必须首先详细了解生产期望目标，然后才能评估解决方案的可维持性。 如果没有明确的目标，则无法评估准备情况。 一组设计良好的性能目标很关键，因为它能使您的策略以系统测试和系统证书为中心。 您的性能目标应包含以下要素：

• 将性能定义为时间的函数的曲线。 这些函数可以非常简单，也可以非常复杂。

• 与性能函数相关联的性能要求。

• 文件大小和类型的分布。

示例 1

• 每天，消息从早上 8:00 的每秒 0 条消息逐渐增加到中午的每秒 80 条消息，然后在晚上 9:00 又回落到每秒 0 条消息，大体上为钟形曲线的形式。

• 系统对每个消息没有具体的延迟要求，但它必须能够处理此负载，以及在不延期的情况下处理前一天的所有消息负载（例如，在发生 24 小时系统停用的情况下）。

• 有三种文档类型：销售篮、延期交货订单和库存请求。 销售篮文档的大小介于 2 到 10 KB 之间，并且在任何给定时间都占消息数的 75%。 延期交货订单文档和库存请求文档的大小都始终在 1 KB 左右，在任何给定时间分别占剩余消息数的 10% 和 15%。

示例 2

• 每天晚上午夜，一批 500,000 条消息将到达进行处理。

• 批处理中的所有消息都必须在 8 小时内完成。

• 所有消息的类型相同，均匀分布在 10 到 50 千字节（含）之间。 此外，批处理始终包含 10 个目录类型消息，每个消息为 10 MB，必须细分为单独的目录条目进行处理。

示例 3

• 每天早上 8：00,4000 名客户服务代表登录到交互式系统，平均每个代表每分钟执行 4 次查询，直到下午 5：00，每周 7 天。

• 所有查询必须在 2 秒内返回结果。

• 所有查询的类型相同，大小在 500 到 1000 字节之间均匀分布（包括 500 到 1000 字节）。

与性能函数关联的性能要求

继续上述示例：

• 示例 1 (继续) ：系统对每条消息没有特定的延迟要求，但它必须能够处理此负载，以及前一天的所有消息加载 (例如，如果系统中断 24 小时，) 不会落后。

• 示例 2 (继续) ：批处理中的所有消息都必须在 8 小时内完成。

• 示例 3 (继续) ：所有查询必须在 2 秒内返回结果。

文件大小和类型的分布

• 示例 1 (继续) ：有三种文档类型：Sales Basket、Back Order 和 Stock Request。 销售篮文档的大小介于 2 到 10 KB 之间，并且在任何给定时间都占消息数的 75%。 延期交货订单文档和库存请求文档的大小都始终在 1 KB 左右，在任何给定时间分别占剩余消息数的 10% 和 15%。

• 示例 2 (继续) ：所有消息的类型相同，平均分布在 10 到 50 KB（含）之间。 此外，批处理始终包含 10 个目录类型消息，每个消息为 10 MB，必须细分为单独的目录条目进行处理。

• 示例 3 (继续) ：所有查询的类型相同，大小在 500 到 1000 字节之间均匀分布（含）。

考虑其他进程

除了直接通过 BizTalk 引擎传递的负载配置文件外，始终有其他进程在同一硬件上争用资源。 这些其他过程将降低系统的整体可持续性能能力。 数据库维护可能是此类过程的最常见示例。

每个数据库（无论大小）都需要定期的操作维护，例如日志传送、备份、存档和清除。 监视和故障排除是定义和认证可持续操作时必须考虑的其他操作示例。 例如，查询 MessageBox (例如，通过管理控制台“组中心”页) 查看过去 24 小时内挂起了多少封给定类型的邮件，需要来自SQL Server的资源，这些资源本来可用于处理邮件。

下面是通常对BizTalk Server整体可持续性影响最大的活动列表：

• 日志传送和备份。 作为涉及SQL Server的大多数灾难恢复计划的一部分，必须对所有BizTalk Server组数据库定期执行日志传送和备份。 有关详细信息，请参阅备份和还原BizTalk Server数据库。 另请参阅 日志传送。

• 存档和清除跟踪数据。 除了总体日志传送和备份计划外，BizTalk 跟踪 (BizTalkDTADb) 数据库还具有自己的存档和清除机制;有关详细信息，请参阅 存档和清除 BizTalk 跟踪数据库。 在 BizTalk 跟踪数据库中存档和清除数据的速度尤其重要，因为在使用跟踪功能时这些操作通常会成为瓶颈。

• 系统查询。 使用 API 或 BizTalk Server 管理控制台 UI 对系统运行各种类型的查询将影响可持续性能。

• MessageBox 维护。 有许多 SQL 作业是BizTalk Server的核心功能的一部分，这些作业通过清理已完成处理的消息和实例来维护 MessageBox 数据库。 作为核心引擎的一部分，完成这些作业的速度是衡量可维持性的重要因素。 有关这些作业及其角色的详细信息，请参阅 维护 BizTalk Server1。

• 解决方案部署活动。 在部署、绑定和启动新应用程序或现有应用程序的新版本时，将会增加 BizTalk 的负载，例如对 MessageBox 数据库创建新的订阅。 部署应用程序后，正在处理的消息将争用资源，从而影响现有应用程序的性能。

  对于其中每个方面，你需要问：你有什么建议来尽量减少这些活动的影响？ 例如，他们是否应该计划在凌晨 3 点运行它们？

考虑计划内和计划外中断

中断对系统性能的影响因遇到中断的系统而异，但最常见的后果是：

• Floodgate 事件。 当系统关闭一段时间时，消息可能会累积起来，然后在系统再次正常运行后立即到达所有消息进行处理。 例如，如果 BizTalk 上运行的应用程序通过 MSMQ 接收消息，并且该应用程序已关闭一段时间，则会在等待选取的队列中生成消息。 再次启动应用程序时，就好像“一次收到大量消息”。

• 消息积压工作。 当消息发送到的系统关闭时，通常会采用使用其他资源的重试周期。 重试周期用完后，消息通常会挂起。 然后，被关闭的系统返回在线，发生一种泛洪门事件，现在可以恢复和/或成功发送大量消息。

  当然，在设计和认证系统时，必须考虑任何计划内中断（例如定期计划维护）。 还建议考虑对计划外中断及其影响进行分析。

  通过标识可能发生的停用类型，按预计风险级别（即，概率乘以严重性）进行排序，并评估具有较高风险的停用情况的持续时间和影响（例如，水闸事件、挂起的消息量、积压等），可以指示发生停用情况时所需的系统性能。 任何基于存储和转发的、基于消息传送的异步系统（如BizTalk Server）都应设计为处理足以应对计划内和计划外中断的“留出空间”。

另请参阅

引擎持久性和持续性
分阶段描述的项目规划建议
测量最大可持续引擎吞吐量
度量最大可承受跟踪吞吐量
缩放解决方案
确定性能瓶颈
引擎性能和容量