消息注意事项
BizTalk Server提供了一组用于发送、接收、转换和处理消息的大量功能。 其中部分功能包括：
能够使用多个行业标准传输（例如 HTTP、SMTP、FTP/FTPS 和 WCF）发送和接收消息。 使用 BizTalk Server 适配器实现对发送和接收消息的传输级别支持。 BizTalk Server消息处理与各种“业务线” (LOB) 应用程序集成是使用众多可用BizTalk Server加速器或适配器之一（例如 BizTalk Accelerator for HIPAA、BizTalk Accelerator for SWIFT 或 BizTalk SAP 适配器）实现的。 这些加速器和适配器符合行业标准，这些行业标准反过来又能将BizTalk Server与符合特定行业标准的系统直接集成。
能够处理多种消息格式，例如纯文本、XML、二进制等。 此功能对于提供BizTalk Server与各种贸易合作伙伴的集成至关重要。
支持消息转换或文档映射。 映射适应不同架构之间的数据转换。 例如，映射可用于将收到的客户采购订单的内容转换为收据，其中包含要发送回客户的发货通知。
BizTalk Server业务流程提供了用于创建跨时间、组织、应用程序和人员的业务流程的功能。 BizTalk Server提供了业务流程Designer图形界面，用于开发业务流程，其中包括对事务的支持 (传统的“原子”MSDTC 类型和长时间运行的) 、异常处理、调试、跟踪和调用外部代码的扩展性。
注意
有关在 BizTalk Server 中使用业务流程时要遵循的最佳做法的指导，请参阅优化业务流程性能。 有关使用业务流程Designerhttps://go.microsoft.com/fwlink/?LinkId=158997 的详细信息，请参阅BizTalk Server文档中的主题使用业务流程Designer () 创建业务流程。
本主题的其余部分介绍与在BizTalk Server环境中处理的消息的大小、复杂性和分布配置文件相关的性能注意事项。
消息大小注意事项
虽然BizTalk Server对消息大小没有限制，但实际限制和依赖项可能需要将消息的大小降至最低，因为大型消息需要更多的处理资源。 随着消息大小的增加，每秒处理的消息数 (总吞吐量) 降低。 在设计方案和规划容量时，请考虑平均消息大小、消息类型和消息数BizTalk Server进程。 不要使用不必要的长属性和标记名称;如果可能，请将长度保持在 50 个字符以内。 例如，不要对只有 1 字节的消息大小使用 200 个字符的标记名称。
如果收到的消息的内存中大小超过在 BizTalk Server 管理控制台) 中 BizTalk 组的“组属性”页上配置的“大型消息片段大小 (指定的字节数，则消息将拆分为指定大小的片段。 此外，这些片段将写入 Microsoft 分布式事务处理协调器 (MSDTC) 事务上下文下的 Messagebox，如下所示：
如果在现有 MSDTC 事务的上下文中发布传入消息，则在将消息片段写入 BizTalk MessageBox 数据库时使用此事务。 例如，如果传入消息由配置为需要事务的事务适配器发布，则将消息片段写入 MessageBox 数据库时使用现有事务。
如果未在现有 MSDTC 事务的上下文中发布传入消息，则会创建一个新的 MSDTC 事务，以将消息片段写入 MessageBox 数据库。 在此方案中，需要注意以下事项：
增大 “大型消息片段大小 ”的值，以减少大型消息分段的频率，并减少创建关联 MSDTC 事务的发生。 因此应该增大此值，因为过多使用 MSDTC 事务将极大地影响系统性能。 请注意，增大此值还可能增加要使用的可用内存量。
如果将消息写入 MessageBox 所花费的时间超过允许的最大 MSDTC 事务超时时间 60 分钟，则事务超时，将发生错误，并且写入消息的尝试将失败并回滚。 处理非常大的消息时，应将 “大型消息片段大小” 值增大到足以避免此问题。 根据可用内存的大小，可将此值提高到 1000000 字节的最大值。
消息中的每个消息片段都可针对 MessageBox 数据库创建一个或多个 SQL Server 数据库锁定。 当锁数超过几十万时，SQL Server可能会生成“锁定外”错误。 如果出现此问题，请增大“大型邮件片段大小”的值以减少片段数 (这会减少针对 MessageBox 数据库) SQL Server数据库锁的数目，或者考虑将 MessageBox 数据库放在 64 位版本的 SQL Server 上。 64 位版本的 SQL Server 的可用锁数明显高于 32 位版本的 SQL Server。 当 MessageBox 数据库位于 32 位版本的 SQL Server 上时，以下公式可用于估算每个交换的最大消息数：
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
有关BizTalk Server处理大型消息的详细信息，包括处理大型消息的准则，请参阅如何BizTalk Server处理大型消息 (https://go.microsoft.com/fwlink/?LinkID=154680) 。
消息类型注意事项
消息以以下两种主要格式之一接收到BizTalk Server：XML 文件或平面文件。 由于 XML 和平面文件消息的资源要求不同，消息类型应始终纳入消息分发配置文件。
XML 文件为了使BizTalk Server对传递路由以外的消息执行任何处理，该消息必须采用 XML 文件格式。
平面文件平面文件必须分析为 XML 格式，BizTalk Server才能执行传递路由以外的任何处理。 将平面文件解析为 XML 文件将极大地增加文件大小。 因为平面文件不包含带有关于其数据的描述性信息的 XML 标记。 另一方面，XML 文件还在描述性 XML 标记中包装了其所有数据。 在某些情况下，分析可以将平面文件的大小增加 10 倍或更多，具体取决于文件 XML 标记中包含的描述性数据量。
包装在 XML 文档中的单个 CDATA 节节点中的平面文件文档这种类型的文档是 XML 和平面文件的组合，通常占用大量内存，因为BizTalk Server必须在处理之前将整个已包装的平面文件文档加载到内存中。
重载注意事项
大多数BizTalk Server应用程序不会以特定的恒定速率接收消息。 通常，消息处理受到峰值和谷值限制。 例如，网上银行应用程序可能首先在早上处理更多的消息，然后在一天中处理，在一天结束时处理。 应测试BizTalk Server解决方案，以确保它们能够处理这些重载方案。 若要确定BizTalk Server解决方案处理重载情况的方式，应确定BizTalk Server解决方案的最大可持续吞吐量 (MST) 。 MST 是系统在生产环境中可以无限期处理的最大消息流量负载。 有关 MST 的详细信息，请参阅规划持续性能 (https://go.microsoft.com/fwlink/?LinkID=158065) 和什么是可持续性能？ (https://go.microsoft.com/fwlink/?LinkID=132304 BizTalk Server文档中的) 。
架构复杂性
消息分析 (特别是平面文件分析) 的吞吐量受架构复杂性的影响。 随着架构复杂性的增加，整体性能会降低。 设计架构时，请减少节点名称的长度，并将升级的属性移动到架构的顶部。 这减少了检索时间，从而提高了性能。
映射复杂性
根据映射的复杂性，地图转换可能会占用大量资源。 随着映射复杂性的增加，整体性能会降低。 若要提高整体性能，请最大程度地减少映射中使用的链接和 functoid 的数量，尤其是调用外部资源的 functoid，如数据库查找 functoid。
平面文件分析注意事项
对平面文件分析性能影响最大的两个因素是文件大小和架构复杂性。 不明确的架构是包含许多可选字段的架构。 使用大文件大小时，具有许多可选字段的架构可能会降低性能，因为较大的文件可能与架构的不同分支匹配。 与对较大文件相比，架构复杂性对较小文件的影响较小。