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，同时不允许任何其他主机访问文件共享。

备注

虽然创建其他主机实例有好处，但如果创建的主机实例太多，也有潜在的缺点。 每个主机实例都是一个 Windows 服务 (BTSNTSvc.exe) ，它针对 MessageBox 数据库生成附加负载，并消耗计算机资源 (CPU、内存、线程) 。

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

配置专用跟踪主机

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

使用专用跟踪主机还可以停止其他 BizTalk 主机，而不会干扰BizTalk Server跟踪。 跟踪数据移出 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 事件总线服务”。https://go.microsoft.com/fwlink/?LinkId=101590

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

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

) 经典模式下 IIS 6.0 和 IIS 7.0 (辅助角色和 I/O 线程数，或者托管作为 Web 服务发布的业务流程的 ASP.NET Web 应用程序的并发执行请求数 (IIS 7.0 集成模式) 应进行修改：

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

• ASP.NET Apps v2.0.50727\请求等待时间或 ASP.NET Apps v2.0.50727\请求执行时间性能计数器的值异常高。

• 与托管 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 更改。 可以在 reqistry 或 aspnet.config 文件的 config 节中指定 maxConcurrentThreadsPerCPU 值。 按照以下步骤更改 maxConcurrentThreadsPerCPU 的默认值，以控制并发执行的请求数：

在注册表中设置 maxConcurrentThreadsPerCPU 值

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

警告

你自行承担使用注册表编辑器的风险。 不正确的使用可能会导致问题，需要重新安装操作系统。 有关如何备份、还原和修改注册表的详细信息，请参阅 Microsoft 知识库文章 256986 - 高级用户的 Windows 注册表信息。

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 线程池分配足够的线程以防止线程不足。 发生线程不足时，没有足够的线程可用于执行对性能产生负面影响的请求工作。 同时，应注意防止将线程分配给 the.NET 与主机关联的线程池所需的线程数。 为与主机相关联的 .NET 线程池分配过多的线程会增加上下文切换。 当 Windows 内核从运行一个线程切换到另一个线程时，会发生上下文切换，这会产生性能成本。 过多的线程分配可能会导致过度的上下文切换，这将对整体性能产生负面影响。

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

警告

对注册表编辑器的不当使用可能会引起问题，而必须重新安装操作系统。 请慎用注册表编辑器，风险自负。 有关如何备份、还原和修改注册表的详细信息，请参阅 上的 Microsoft 知识库文章“Microsoft Windows 注册表的说明”。https://go.microsoft.com/fwlink/?LinkId=62729

备注

工作线程 用于处理排队的工作项， I/O 线程 是与 I/O 完成端口关联的专用回调线程，用于处理已完成的异步 I/O 请求。

若要修改与 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
   最大工作线程数	25	100 重要提示：将此值增大到超过 100 可能会对托管 BizTalk Server MessageBox 数据库的SQL Server计算机的性能产生不利影响。 当发生此问题时，SQL Server 可能会遇到死锁情况。 建议不要将此参数增大到超过 100 的值。
   MinIOThreads	1	25
   MinWorkerThreads	1	25

   备注

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

   备注

   这些值隐式乘以服务器上的处理器数。 例如，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 天。 有关配置清除间隔的详细信息，请参阅 帮助中的“如何配置 DTA 清除和存档作业”BizTalk Server帮助https://go.microsoft.com/fwlink/?LinkID=104908。

安装最新服务包

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

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

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

BizTalk Server文档中的性能优化

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

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

• “识别性能瓶颈”位于 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