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

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

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

应创建单独的主机来发送、接收、处理和跟踪功能。 在 BizTalk 组中配置工作负荷时，创建多个 BizTalk 主机可提供灵活性，并且是主要在 BizTalk 组中的 BizTalk 服务器之间分发处理的方法。 多个主机还允许停止一个主机，而不会影响其他主机。 例如，你可能希望停止发送消息，让他们在 Messagebox 数据库中排队，同时仍允许入站接收邮件。 按功能分隔主机实例也具有以下优势：

• 每个主机实例都有自己的一组资源，例如 .NET 线程池中的内存、句柄和线程。

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

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

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

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

配置专用跟踪主机

BizTalk Server 针对吞吐量进行优化，因此主业务流程和消息传送引擎实际上不会直接将消息移动到 BizTalk 跟踪或 BAM 数据库，因为这会将这些引擎从执行业务流程的主要作业转移出来。 相反，BizTalk Server 将消息保留在 MessageBox 数据库中，并将它们标记为需要移动到 BizTalk 跟踪数据库。 然后，后台进程（跟踪主机）将消息移动到 BizTalk 跟踪和 BAM 数据库。 由于跟踪是一项资源密集型作，因此应创建专用于跟踪的单独主机，从而最大限度地减少跟踪对专用于消息处理的主机的影响。

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

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

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

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

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

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

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

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

• “管理 BAM 事件总线服务” at https://go.microsoft.com/fwlink/?LinkId=101590.

• “创建 BAM 事件总线服务的实例” at https://go.microsoft.com/fwlink/?LinkId=101591.

管理 ASP.NET 线程使用情况或并发执行请求，以支持将业务流程作为 Web 或 WCF 服务发布的 Web 应用程序

在以下情况下，应修改托管作为 Web 服务发布的业务流程的 ASP.NET Web 应用程序的工作线程和I/O线程数量（IIS 6.0 和 IIS 7.0 经典模式）或并发执行请求数（IIS 7.0 集成模式）：

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

• 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: 6/4/2009
  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 6.0 和 IIS 7.0 上运行业务流程的 Web 应用程序的 ASP.NET 线程使用情况

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

<processModel autoConfig="true" />

若要手动修改 ASP.NET 2.0 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=66483）。

管理在集成模式下运行的 IIS 7.0 上托管业务流程的 Web 应用程序的并发执行请求数

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

在注册表中设置 maxConcurrentThreadsPerCPU 值

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

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

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

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

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

   2. 键入 maxConcurrentThreadsPerCPU，然后按 Enter。

   3. 在 maxConcurrentThreadsPerCPU 密钥下，创建具有 maxConcurrentThreadsPerCPU 的新值的 DWORD 条目。

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

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

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

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

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

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

   注释

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

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

由于 Windows 线程是 Windows 进程可用的最基本的可执行单元，因此请务必将足够的线程分配给与 BizTalk 主机实例关联的 .NET 线程池，以防止线程饥饿。 发生线程饥饿时，没有足够的线程可用于执行对性能产生负面影响的请求工作。 同时，应注意不要向与主机关联的 .NET 线程池分配超过必要的线程。 将过多线程分配给与主机关联的 .NET 线程池可能会增加上下文切换。 当 Windows 内核从运行一个线程切换到另一个线程时，会发生上下文切换，这会产生性能成本。 过多的线程分配可能会导致过度的上下文切换，这将对整体性能产生负面影响。

通过在 BizTalk Server 注册表中创建相应的 CLR 托管值，修改与 BizTalk 主机实例关联的 .NET 线程池中可用的 Windows 线程数。

若要修改与 BizTalk 主机的每个实例关联的 .NET 线程池中可用的线程数，请执行以下步骤：

1. 停止 BizTalk 主机实例。

2. 单击“ 开始”，单击“ 运行”，键入 regedit.exe，然后单击“ 确定 ”以启动注册表编辑器。 导航到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname ，其中 主机名 是与主机实例关联的主机的名称。

   注释

   如果已从 BizTalk Server 2004 升级 BizTalk Server 2006 安装，则此注册表项可能表示为 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcguid ， 其中 guid 是 BizTalk Server 主机的每个实例唯一的 GUID。

3. 找到 CLR 托管 密钥。 如果此密钥不存在，请按照以下步骤创建密钥：

   1. 在“编辑”菜单上，单击“新建”，然后单击“项”。

   2. 键入 CLR 宿主，然后按 Enter。

4. 在 CLR 宿主 密钥下，使用指示的值创建以下 DWORD 条目。

   DWORD 条目	默认值	建议的值
   MaxIOThreads	20	100
   MaxWorkerThreads	二十五	100 重要提示： 将此值提高到 100 之后可能会对托管 BizTalk Server MessageBox 数据库的 SQL Server 计算机的性能产生负面影响。 出现此问题时，SQL Server 可能会遇到死锁情况。 建议此参数不超过 100 的值。
   MinIOThreads	1	二十五
   MinWorkerThreads	1	二十五

   注释

   对于大多数方案，这些建议的值将足够，但可能需要根据每个主机实例中运行的适配器处理程序或业务流程数量增加。

   注释

   这些值隐式乘以服务器上的处理器数。 例如，将 MaxWorkerThreads 条目设置为值 100 会有效地在 4 个 CPU 服务器上设置 400 值。

5. 关闭注册表编辑器。

6. 重启 BizTalk 主机实例。

在不需要跟踪时禁用对业务流程、发送端口、接收端口和管道的跟踪

跟踪在 BizTalk Server 中会产生性能开销，因为数据必须写入 MessageBox 数据库，然后异步移动到 BizTalk 跟踪数据库。 如果跟踪不是业务需求，则禁用跟踪以减少开销并提高性能。 有关配置跟踪的详细信息，请参阅 BizTalk Server 帮助 https://go.microsoft.com/fwlink/?LinkID=106742中的“使用 BizTalk Server 管理控制台配置跟踪”。

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

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

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

安装最新服务包

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

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

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

BizTalk Server 文档中的性能优化

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

• “排查消息框延迟问题” https://go.microsoft.com/fwlink/?LinkId=114747

• “识别性能瓶颈” at https://go.microsoft.com/fwlink/?LinkID=104418

• “避免 DBNETLIB 异常” https://go.microsoft.com/fwlink/?LinkID=108787

• “避免 TCP/IP 端口枯竭” https://go.microsoft.com/fwlink/?LinkID=101610

• “设置 EPM 线程池大小” https://go.microsoft.com/fwlink/?LinkId=114748