BizTalk Server 的常规优化 - 第 1 部分

以下建议可用于提高 BizTalk Server 性能。 安装并配置 BizTalk Server 后，将应用本主题中列出的优化。

配置 MSDTC

若要促进 SQL Server 与 BizTalk Server 之间的事务，必须启用Microsoft分布式事务处理协调器（MS DTC）。 若要在 BizTalk Server 上配置 MSDTC，请参阅有关 提高作系统性能的一般准则。

有关配置 BizTalk Server 主机的建议

本部分提供有关配置 BizTalk Server 主机的建议。

按功能创建多个 BizTalk Server 主机和单独的主机实例

按照以下准则创建多个 BizTalk Server 主机，并跨这些主机分配工作负荷：

• 创建单独的主机用于发送、接收、处理和跟踪功能。 在 BizTalk 组中配置工作负荷时，创建多个 BizTalk 主机提供了灵活性，并且是跨 BizTalk 组中运行 BizTalk Server 的计算机分发处理的主要手段。 使用多个主机可以停止一个主机，而不会影响其他主机。 例如，你可能希望停止发送消息，让这些消息在 MessageBox 数据库中排队，同时仍允许在不同的主机实例中运行的接收适配器接收入站消息。 按功能分隔主机实例也具有以下优势：

  • 运行多个 BizTalk 主机可减少 MessageBox 数据库主机队列表的争用，因为每个主机在 MessageBox 数据库中分配了自己的工作队列表。

  • 限流在 BizTalk Server 的主机级别实现。 这允许为每个主机设置不同的限流特征。

  • 安全性在主机级别实现;每个主机在离散 Windows 标识下运行。 例如，这允许你向Host_A授予对FileShare_B的访问权限，同时不允许任何其他主机访问文件共享。

• 每个主机实例都有自己的一组资源，例如 .NET 线程池中的内存、句柄和线程。 在跨主机分配工作负荷时，建议考虑将一起扩展的资源放置在同一主机中。

• 将适配器和编排分开，以便在不同的主机中根据资源的不同优先级进行管理。 此技术适应将运行高优先级应用程序的主机置于专用 BizTalk Server 计算机上。

有关修改 BizTalk Server 主机属性的详细信息，请参阅 BizTalk Server 2010 帮助中的 “如何修改主机属性 ”（https://go.microsoft.com/fwlink/?LinkID=154359）。

配置专用跟踪主机

BizTalk Server 针对吞吐量进行优化，因此主业务流程和消息传送引擎实际上不会直接将消息移动到 BizTalk 跟踪或 BAM 数据库，因为这会将这些引擎从执行业务流程的主要作业转移出来。 相反，BizTalk Server 将消息保留在 MessageBox 数据库中，并将它们标记为需要移动到 BizTalk 跟踪数据库。 然后，后台进程（跟踪主机）将消息移动到 BizTalk 跟踪和 BAM 数据库。 由于跟踪是一项资源密集型作，因此应创建专用于跟踪的单独主机，从而最大限度地减少跟踪对专用于消息处理的主机的影响。 为了获得最佳性能，每个 MessageBox 数据库应至少有一个跟踪主机实例。 跟踪主机实例的实际数目应为 N + 1，其中 N = MessageBox 数据库数。 “+ 1”用于冗余，以防托管跟踪的计算机之一失败。

使用专用的跟踪主机还可以停止其他 BizTalk 主机，而不会干扰到 BizTalk 服务器的跟踪。 将跟踪数据从 MessageBox 数据库中移出对于 BizTalk Server 系统的健康运行至关重要。 如果负责移动 BizTalk 组中跟踪数据的 BizTalk 主机已停止，跟踪数据解码服务将不会运行。 其影响如下：

• 不会将 HAT 跟踪数据从 MessageBox 数据库移动到 BizTalk 跟踪数据库。

• BAM 跟踪数据不会从 MessageBox 数据库移动到 BAM 主导入数据库。

• 由于数据未移动，因此无法从 MessageBox 数据库删除数据。

• 当跟踪数据解码服务停止时，跟踪拦截器仍将触发并将跟踪数据写入 MessageBox 数据库。 如果未移动数据，这将导致 MessageBox 数据库膨胀，这会影响随时间推移的性能。 即使未跟踪自定义属性或未设置 BAM 配置文件，默认情况下也会跟踪某些数据（例如管道接收/发送事件和业务流程事件）。 如果不想运行跟踪数据解码服务，请关闭所有跟踪，以便没有拦截器将数据保存到数据库。 若要禁用全局跟踪，请参阅 BizTalk Server 2010 帮助中的 “如何关闭全局跟踪 ”（https://go.microsoft.com/fwlink/?LinkID=154193）。 使用 BizTalk Server 管理控制台选择性地禁用跟踪事件。

  跟踪主机应至少在运行 BizTalk Server 的两台计算机上运行（如果出现一个失败时需要冗余）。 为了获得最佳性能，每个 MessageBox 数据库应至少有一个跟踪主机实例。 跟踪主机实例的实际数目应为 （N + 1），其中 N = MessageBox 数据库数。 “+ 1”用于冗余，以防托管跟踪的计算机之一失败。

  跟踪主机实例移动特定 MessageBox 数据库的跟踪数据，但不会有多个跟踪主机实例移动特定 MessageBox 数据库的数据。 例如，如果你有三个 MessageBox 数据库，并且只有两个跟踪主机实例，则其中一个主机实例需要移动两个 MessageBox 数据库的数据。 添加第三个跟踪主机实例会将跟踪主机工作分发给运行 BizTalk Server 的另一台计算机。 在此方案中，添加第四个跟踪主机实例不会再分配任何跟踪主机工作，但会为容错提供额外的跟踪主机实例。

  有关 BAM 事件总线服务的详细信息，请参阅 BizTalk Server 2010 帮助中的以下主题：

• 管理 BAM 事件总线服务 （https://go.microsoft.com/fwlink/?LinkID=154194）。

• 创建 BAM 事件总线服务的实例 （https://go.microsoft.com/fwlink/?LinkID=154195）。

除非绝对必要，否则不要群集 BizTalk 主机

虽然 BizTalk Server 2010 允许将 BizTalk 主机配置为群集资源，但仅当需要为无法跨多个 BizTalk 计算机托管的资源提供高可用性时，才应考虑这样做。 例如，使用 FTP 适配器的端口应仅驻留在一个主机实例上，因为 FTP 协议不提供文件锁定。 然而，这引入了单点故障，这可以通过群集来解决。 包含适配器的主机（如文件、SQL、HTTP 或仅处理主机）可以在计算机内部进行负载均衡，但不适用于群集。

通过更改 maxconnection 参数的值增加允许的 HTTP 并发连接数

默认情况下，HTTP 适配器（包括基于 WCF 的 HTTP 适配器）仅打开两个从运行 BizTalk Server 的每台计算机到任何特定目标服务器的并发 HTTP 连接。

此设置符合 HTTP 1.1 规范的 IETF RFC，尽管它适用于用户方案，但它未针对高吞吐量进行优化。 该设置有效地限制每个服务器的出站 HTTP 调用，使其从运行 BizTalk Server 的每台计算机只能进行两个并发发送。

若要增加并发连接数，可以在每个 BizTalk Server 上修改 BizTalk Server 配置文件中 maxconnection 参数的值，BTSNTSvc.exe.config（或 64 位主机的 BTSNTSvc64.exe.config）。 可以为要调用的特定服务器增加此值。 根据经验法则，maxconnection 参数的值应设置为 12 * 承载 Web 应用程序的计算机上的 CPU 或核心数。

下面是最大连接属性的配置示例：

<configuration>
  <system.net>
    <connectionManagement>
      <add address="http://www.contoso.com" maxconnection="24" />
      <add address="*" maxconnection="48" />
    </connectionManagement>
  </system.net>
</configuration>

设置 maxconnection 属性时，可以指定 HTTP、HTTPS、网站的 IP 地址和端口号。 其他示例包括：

<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />

有关优化 Web 服务的 IIS 和 ASP.NET 设置的详细信息，请参阅 BizTalk Server 2010 帮助中 影响适配器性能的配置参数 的https://go.microsoft.com/fwlink/?LinkID=154200“ASP.NET 设置影响 HTTP 适配器性能”部分。

管理 ASP.NET 线程使用情况或并发执行可托管独立接收位置、后端 Web 服务和 WCF 服务的 Web 应用程序的请求

在以下条件下，托管独立接收位置、后端 Web 服务和 WCF 服务的 ASP.NET Web 应用程序的工作线程和 I/O 线程数（IIS 7.5 和 IIS 7.0 的经典模式）或并发执行请求数（IIS 7.5 和 7.0 的集成模式）应进行修改：

• CPU 使用率不是托管 Web 服务器上的瓶颈。

• 数值：

  • ASP.NET Apps v4.0.30319 \Request Wait Time 或 ASP.NET Apps v4.0.30319 \Request Execution Time 性能计数器的数值异常偏高。

  • ASP.NET Apps v2.0.50727\Request Wait Time 或 ASP.NET Apps v2.0.50727\Request Execution Time 性能计数器异常高。

• 在承载 Web 应用程序的计算机的应用程序日志中生成类似于以下内容的错误。

  Event Type: Warning
  Event Source: W3SVC Event Category: None
  Event ID: 1013
  Date: 11/4/2010
  Time: 1:03:47 PM
  User: N/A
  Computer: <ComputerName>
  Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'
  

管理可在经典模式下运行的 IIS 7.5 和 IIS 7.0 上托管独立接收位置、后端 Web 服务和 WCF 服务的 Web 应用程序的 ASP.NET 线程使用情况

当经典模式下运行的 IIS 7.5 和 IIS 7.0 服务器的 machine.config 文件中 的 autoConfig 值设置为 true 时，ASP.NET 2.0 和 ASP.NET 4 管理分配给任何关联的 IIS 工作进程的工作线程数和 I/O 线程数。

<processModel autoConfig="true" />

若要手动修改 ASP.NET 2.0 和 ASP.Net 4 Web 应用程序的辅助角色和 I/O 线程数，请打开关联的 machine.config 文件，然后输入 maxWorkerThreads 和 maxIoThreads 参数的新值。

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

有关调整 ASP.NET 2.0 Web 应用程序的 machine.config 文件中的参数的详细信息，请参阅 Microsoft 知识库文章 821268 争用、性能不佳，从 ASP.NET 应用程序发出 Web 服务请求时死锁 （https://go.microsoft.com/fwlink/?LinkID=144169）。

管理并发执行 ASP.NET 2.0 Web 应用程序的请求数，这些应用程序可以托管在集成模式下运行的 IIS 7.5 和 IIS 7.0 上的隔离接收位置、后端 Web 服务和 WCF 服务

当 ASP.NET 2.0 托管在集成模式下的 IIS 7.5 和 IIS 7.0 上时，线程的使用方式与在经典模式下的 IIS 7.5 和 IIS 7.0 上的使用方式不同。 ASP.NET 2.0 托管在集成模式下的 IIS 7.5 和 IIS 7.0 上时，ASP.NET 2.0 会限制并发执行 的请求 数，而不是并发执行请求的 线程 数。 对于同步方案，这将间接限制线程数，但对于异步方案，请求数和线程数可能会大相径庭。 在集成模式下在 IIS 7.5 和 IIS 7.0 上运行 ASP.NET 2.0 时，machine.config 文件中 的 maxWorkerThreads 和 maxIoThreads 参数不用于控制正在运行的线程数。 相反，通过修改为 maxConcurrentRequestsPerCPU 指定的值，可以将并发执行的请求数从每个 CPU 的默认值 12 更改。 maxConcurrentRequestsPerCPU 值可以在 reqistry 或 aspnet.config 文件的 config 节中指定。 按照以下步骤更改 maxConcurrentRequestsPerCPU 的默认值，以控制并发执行的请求数：

在注册表中设置 maxConcurrentRequestsPerCPU 值

此设置是全局设置，不能更改单个应用程序池或应用程序。

1. 在 “开始 ”菜单中，找到并启动 “运行 ”提示符，输入 regedit.exe，然后选择“ 确定 ”以启动注册表编辑器。

2. 导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

3. 按照以下步骤创建密钥：

   1. 在“编辑”菜单上，选择“新建”，然后选择“键”。

   2. 键入 maxConcurrentRequestsPerCPU，然后按 Enter。

   3. 在 maxConcurrentRequestsPerCPU 密钥下，使用 maxConcurrentRequestsPerCPU 的新值创建 DWORD 条目。

   4. 关闭“注册表编辑器”。

在 aspnet.config 文件的 config 节中为应用程序池设置 maxConcurrentRequestsPerCPU 值

1. 下载并安装 Microsoft .NET Framework 3.5 Service Pack 1，这是在配置文件中设置以下值所必需的。 完整版也可用。

2. 打开应用程序池的 aspnet.config 文件。

3. 输入 maxConcurrentRequestsPerCPU 和 requestQueueLimit 参数的新值。

   <system.web>
       <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
   </system.web>
   

   注释

   此值替代注册表中为 maxConcurrentRequestsPerCPU 指定的值。 requestQueueLimit 设置与 processModel/requestQueueLimit 相同，但 aspnet.config 文件中的设置将替代 machine.config 文件中的设置。

有关在 IIS 7.0 上配置 ASP.NET 线程使用情况的详细信息，请参阅 Thomas Marquardt 关于 IIS 7.0 上的 ASP.NET 线程使用情况的博客 （https://go.microsoft.com/fwlink/?LinkId=157518）。

管理 ASP.NET 4 个 Web 应用程序的并发执行请求数，这些应用程序可以托管在集成模式下运行的 IIS 7.5 和 7.0 上的隔离接收位置、后端 Web 服务和 WCF 服务

使用 .NET Framework 4 时，maxConcurrentRequestsPerCPU 的默认设置为 5000，这是一个非常大的数字，因此将允许大量异步请求并发执行。 有关详细信息，请参阅 <applicationPool> 元素（Web 设置） （https://go.microsoft.com/fwlink/?LinkID=205339）。

对于 IIS 7.5 和 IIS 7.0 集成模式，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 内名为 MaxConcurrentRequestsPerCPU 的 DWORD 决定了每个 CPU 的并发请求数。 默认情况下，注册表项不存在，每个 CPU 的请求数限制为 5000。

在注册表中设置 maxConcurrentRequestsPerCPU 值

此设置是全局设置，不能更改单个应用程序池或应用程序。

1. 在 “开始 ”菜单中，找到并启动 “运行 ”提示符，输入 regedit.exe，然后选择“ 确定 ”以启动注册表编辑器。

2. 导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0。

3. 按照以下步骤创建密钥：

   1. 在“编辑”菜单上，选择“新建”，然后选择“键”。

   2. 键入 maxConcurrentRequestsPerCPU，然后按 Enter。

   3. 在 maxConcurrentRequestsPerCPU 密钥下，使用 maxConcurrentRequestsPerCPU 的新值创建 DWORD 条目。

   4. 关闭“注册表编辑器”。

在 aspnet.config 文件的 config 节中为应用程序池设置 maxConcurrentRequestsPerCPU 值

1. 下载并安装 Microsoft .NET Framework 4，这是在配置文件中设置以下值所必需的。

2. 打开应用程序池的 aspnet.config 文件。

3. 输入 maxConcurrentRequestsPerCPU 和 requestQueueLimit 参数的新值。

   以下示例中的值是默认值。

   <system.web>
       <applicationPool maxConcurrentRequestsPerCPU="5000" requestQueueLimit="5000"/>
   </system.web>
   

   注释

   此值替代注册表中为 maxConcurrentRequestsPerCPU 指定的值。 requestQueueLimit 设置与 processModel/requestQueueLimit 相同，但 aspnet.config 文件中的设置将替代 machine.config 文件中的设置。

定义 BizTalk 主机实例的 CLR 托管线程值

由于 Windows 线程是 Windows 进程可用的最基本的可执行单元，因此请务必将足够的线程分配给与 BizTalk 主机实例关联的 .NET 线程池，以防止线程饥饿。 发生线程饥饿时，没有足够的线程可用于执行对性能产生负面影响的请求工作。 同时，应注意不要向与主机关联的 .NET 线程池分配超过必要的线程。 将过多线程分配给与主机关联的 .NET 线程池可能会增加上下文切换。 当 Windows 内核从运行一个线程切换到另一个线程时，会发生上下文切换，这会产生性能成本。 过多的线程分配可能会导致过度的上下文切换，这将对整体性能产生负面影响。 分配给 BizTalk 主机实例的 .NET 线程池的默认线程数取决于安装的 .NET Framework 版本。 .NET Framework 4 和 .NET Framework 3.5 SP1 大大增加了默认值，这可能会导致 BizTalk Server 计算机上的线程分配过多，并且 MessageBox 数据库上的锁争用过多。

使用 BizTalk 设置仪表板，可以修改与 BizTalk 主机实例关联的 .NET 线程池中可用的 Windows 线程数的默认值。 有关如何修改 .NET CLR 设置的详细信息，请参阅 如何修改 .NET CLR 设置 （https://go.microsoft.com/fwlink/?LinkID=205344）。 .NET CLR 设置针对每个核心 CPU。

禁用 BizTalk Server 组级跟踪

跟踪在 BizTalk Server 中会产生性能开销，因为数据必须写入 MessageBox 数据库，然后异步移动到 BizTalk 跟踪数据库。 在生产 BizTalk Server 环境中配置跟踪时，需要考虑以下注意事项：

• 根据经验法则，如果跟踪不是业务需求，则禁用组级跟踪以减少开销并提高性能。

  若要禁用 BizTalk Server 组级跟踪，请执行以下步骤：

  1. 在 BizTalk Server 管理控制台中，展开 BizTalk Server 管理，右键单击 BizTalk 组，然后单击“设置”。

  2. 在 BizTalk 设置仪表板对话框中的“组”页上，清除 “启用组级跟踪 ”复选框。

  3. 单击 “确定 ”应用修改并退出“设置仪表板”。

• 仅在必要时使用消息正文跟踪。 根据消息吞吐量和消息大小，消息正文跟踪可能会导致大量开销。 尽管 BizTalk 活动跟踪在调试和审核方面具有明显的优势，但它也具有相当大的性能和可伸缩性影响。 因此，应仅跟踪出于调试和安全原因严格必要的数据，并避免跟踪冗余信息。

• 默认情况下，以下跟踪选项为编排启用：

  • 编排开始和结束

  • 消息发送和接收

  • 形状的起始和终点

    业务流程跟踪选项“形状开始和结束”会产生大量开销，不应在需要高吞吐量的生产环境中启用。 业务流程跟踪选项可在“业务流程属性”对话框的 “跟踪 ”页上的 BizTalk 管理控制台中访问。

  有关配置跟踪的详细信息，请参阅 使用 BizTalk Server 管理控制台配置跟踪 （https://go.microsoft.com/fwlink/?LinkId=158021）。

在高吞吐量方案中，将 DTA 清除和存档作业的清除期从 7 天减少到 2 天

默认情况下，BizTalk Server 中跟踪数据的清除间隔设置为 7 天。 在高吞吐量方案中，这可能会导致跟踪数据库中的数据过度积累，这最终会影响 MessageBox 的性能，进而对消息处理吞吐量产生负面影响。

在高吞吐量方案中，将硬清除间隔从默认值 7 天减少到 2 天。 有关配置清除间隔的详细信息，请参阅 BizTalk Server 2010 帮助中的 如何配置 DTA 清除和存档作业 （https://go.microsoft.com/fwlink/?LinkID=153814）。

将 BizTalk 服务帐户的 %temp% 路径配置为指向单独的磁盘或 LUN

应该这样做，因为 BizTalk 在执行复杂映射操作时使用临时位置将文件流式传输到磁盘。

安装最新服务包

应安装 BizTalk Server 和 .NET Framework 的最新 Service Pack，因为这些服务包包含可以更正可能遇到的性能问题的修补程序。

BizTalk Server 文档中的性能优化

根据需要应用 BizTalk Server 文档中的以下建议：

• MessageBox 延迟问题疑难解答 （https://go.microsoft.com/fwlink/?LinkId=158019）

• 识别性能瓶颈 （https://go.microsoft.com/fwlink/?LinkID=154238）

• 避免 DBNETLIB 异常 （https://go.microsoft.com/fwlink/?LinkID=155308）

• 避免 TCP/IP 端口耗尽 （https://go.microsoft.com/fwlink/?LinkID=153240）

• 设置 EPM 线程池大小 （https://go.microsoft.com/fwlink/?LinkId=158020）

另请参阅

优化 BizTalk Server 性能