在规划和估算系统可持续性时，必须从长期可持续性的角度思考。 主要注意事项包括：
加载配置文件和性能目标：在加载配置文件和性能目标方面，不能有太多的详细信息。 测试和就绪性认证将基于能够长期处理这些负载。
竞争服务器资源的其他活动和进程：它不仅仅是消息加载。 服务器上发生其他进程和活动，这些进程和活动会影响数据库维护和 MessageBox 查询等性能。
计划内和计划外系统中断和停机时间：Floodgate事件和消息积压可以更改有效的负载曲线。
在考虑构建可持续系统以及认证它们的测试时，请务必考虑到这些因素并为其制定计划。
你的性能是否可持续？
在讨论 BizTalk Server 的性能时，我们将定义最大的可持续性能，如下所示：
系统可以在生产环境中无限期处理的消息流量的最大负载。
虽然这看起来很简单，但在评估一个解决方案——在特定硬件上运行——是否能够支持将其投入生产之后每天持续的负载时，必须考虑许多因素。
在将解决方案投入生产之前，请考虑以下因素来评估解决方案是否可以无限期处理消息流量的最高负载：
所需的性能目标和吞吐量/延迟特征。
在同一硬件上运行的其他进程，例如：
正常监视和故障排除
作数据库维护，例如日志传送、备份、清除、索引维护和统计信息更新。
其他应用程序
计划内和计划外系统中断，例如：
导致无法发送或接收消息的合作伙伴网站故障
定期系统维护停机时间
了解性能目标
在评估解决方案的可持续性之前，必须详细了解预期的生产负载。 如果没有理解的目标，则无法评估就绪情况。 一组格式良好的性能目标至关重要，因为它将围绕系统测试和认证推动策略。 性能目标应具有以下元素：
将性能定义为时间函数的曲线。 这些函数的范围从极其简单到非常复杂。
与性能函数关联的性能要求。
文件大小和类型的分布。
示例 1
每天，消息流量从上午 8:00 的 0 信息/秒增加到中午的 80 信息/秒，然后在晚上 9:00 降回到 0 信息/秒，呈现出钟形曲线的趋势。
系统对每个消息没有特定的延迟要求，但它必须能够处理此负载，以及前一天的所有消息加载（例如，如果系统中断 24 小时），而不会落后。
有三种文档类型：Sales Basket、Back Order 和 Stock Request。 销售篮文档的大小介于 2 到 10 KB 之间，在任何给定时间构成 75% 的邮件计数。 补货订单和库存请求文档的大小始终接近1千字节，它们在任何给定时间内分别构成消息计数的剩余部分，其中补货订单为10%，库存请求为15%。
示例 2
每晚午夜时分，一批 50 万条消息到达进行处理。
批处理中的所有消息都必须在 8 小时内完成。
所有消息的类型都相同，大小均匀分布于 10 到 50 千字节之间，包括 10 和 50 千字节。 此外，该批始终包含 10 条目录类型消息，每个消息为 10 兆字节，必须细分为单独的目录条目进行处理。
示例 3
每天上午 8：00,4000 客户服务代表登录到交互式系统，平均每分钟每名代表 4 次查询，直到下午 5：00，每周 7 天。
所有查询都必须在不到 2 秒内返回结果。
所有查询都是相同的类型，并且平均分布大小在 500 到 1000 字节之间，包括 1000 字节。
与性能函数关联的性能要求
继续上述示例：
示例 1 （continued）：系统对每个消息没有特定的延迟要求，但它必须能够处理此负载，以及前一天的所有消息加载（例如，如果系统中断 24 小时），而不会落后。
示例 2 （continued）：批处理中的所有消息都必须在 8 小时内处理完成。
示例 3 （继续）：所有查询都必须在不到 2 秒内返回结果。
文件大小和类型的分布
示例 1 （continued）：有三种文档类型：销售篮、回购和库存请求。 销售篮文档的大小介于 2 到 10 KB 之间，在任何给定时间构成 75% 的邮件计数。 补货订单和库存请求文档的大小始终接近1千字节，它们在任何给定时间内分别构成消息计数的剩余部分，其中补货订单为10%，库存请求为15%。
示例 2 （续）：所有消息的类型相同，均匀分布在 10 到 50 千字节之间，包含 10 和 50 千字节。 此外，该批始终包含 10 条目录类型消息，每个消息为 10 兆字节，必须细分为单独的目录条目进行处理。
示例 3 （continued）：所有查询都是相同的类型，并且平均分布大小为 500 到 1000 字节（含）。
考虑其他进程
除了直接通过 BizTalk 引擎传递的负载配置文件外，始终还有其他进程争用同一硬件上的资源。 这些其他流程将降低系统的整体可持续性能能力。 数据库维护可能是此类进程的最常见示例。
每个数据库（无论大小）都需要定期的作维护，例如日志传送、备份、存档和清除。 监视和故障排除是定义和认证可持续作时必须考虑的其他作示例。 例如，查询 MessageBox 的信息（例如，通过管理控制台组中心页面）以查看过去 24 小时内已挂起的给定类型消息数，需要使用 SQL Server 的资源，而这些资源本可以用于处理消息。
下面是通常对 BizTalk Server 整体可持续性影响最大的活动列表：
日志传送和备份。 作为涉及 SQL Server 的大多数灾难恢复计划的一部分，必须为所有 BizTalk Server 组数据库定期执行日志传送和备份。 有关详细信息，请参阅 备份和还原 BizTalk Server 数据库。 另请参阅 日志传送。
存档和清除跟踪数据。 除了总体日志传送和备份计划外，BizTalk 跟踪（BizTalkDTADb）数据库还有其自己的存档和清除制度：有关详细信息，请参阅 存档和清除 BizTalk 跟踪数据库。 将数据从 BizTalk 跟踪数据库存档和清除的速度至关重要，因为在跟踪使用中存档和清除 BizTalk 跟踪数据库常常是一个瓶颈。
系统查询。 使用 API 或 BizTalk Server 管理控制台 UI 针对系统运行各种类型的查询会影响可持续性能。
MessageBox 维护。 有许多 SQL 作业是 BizTalk Server 的核心功能的一部分，这些作业通过清理已完成处理的消息和实例来维护 MessageBox 数据库。 作为核心引擎的一部分，这些工作可以完成的速度是衡量可持续性的关键因素。 有关这些作业及其角色的详细信息，请参阅 维护 BizTalk Server1。
解决方案部署活动。 部署、绑定和启动新应用程序或现有应用程序的新版本时，BizTalk 上会放置额外的负载，例如在 MessageBox 数据库上创建新订阅。 部署应用程序后，正在处理的消息将争用资源，从而影响现有应用程序的性能。
对于上述每个领域，你需要问：建议将这些活动的影响降到最低？ 例如，他们是否打算在凌晨 3 点运行它们？
考虑计划内和计划外停机
中断对系统性能的影响因系统遇到中断而有所不同，但最常见的后果是：
洪水门事件。 当系统关闭一段时间时，消息可能会积累，并在系统再次正常运行后一起到达并进行处理。 例如，如果在 BizTalk 上运行的应用程序通过 MSMQ 接收消息，而该应用程序暂时宕机，则消息会在队列中堆积，等待被处理。 当应用程序再次启动时，就好像大量消息“一次性”到达。
消息积压。 将消息发送到的系统关闭时，通常会使用使用其他资源的重试周期。 重试周期用尽后，消息通常会被挂起。 然后，已关闭的系统重新上线，会发生一种泛洪门事件，此时可以恢复和/或成功发送大量消息。
当然，在设计和认证系统时，必须考虑任何计划内中断，例如定期维护。 此外，还建议分析计划外中断及其影响。
确定可能发生的中断类型，按估计的风险级别（即概率与严重性之积）对其进行排名，并估算高风险中断的持续时间和影响（例如，重大事件、暂停的消息量、积压任务等），以便在中断发生时确定所需的系统功能。 应设计任何基于存储和转发消息传送的异步系统（如 BizTalk Server）具有足够的处理余量，以应对计划内和计划外中断。
另请参阅
引擎持久性和持久性
按阶段制定项目规划建议
测量最大可持续引擎吞吐量
测量最大可持续跟踪吞吐量
扩展解决方案
识别性能瓶颈
引擎性能和容量