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

项目
10/04/2023

以下建议可用于提高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计算机上放置运行高优先级应用程序的主机。

备注

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

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

配置专用跟踪主机

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

使用专用跟踪主机还可以停止其他 BizTalk 主机，而不会干扰BizTalk Server跟踪。跟踪数据移出 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 适配器) 仅打开两个并发 HTTP 连接，从运行BizTalk Server到任何特定目标服务器的每台计算机。

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

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

备注

不要将 maxconnection 参数的值增大到如此大的值，以至要调用的 Web 服务器因 HTTP 连接而过载。更改 maxconnection 参数的值后，通过向每个目标 Web 服务器发送请求来执行压力测试，以确定 maxconnection 的值，该值将提供良好的性能和 HTTP 发送，而不会使目标 Web 服务器压倒。

以下为最大连接数属性的配置示例：

<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 帮助BizTalk Server 2010 帮助) 中影响适配器性能的配置参数 () 的“ASP.NET 设置可能会影响 HTTP 适配器性能https://go.microsoft.com/fwlink/?LinkID=154200”部分。

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

经典模式下 (IIS 7.5 和 IIS 7.0 的工作线程和 I/O 线程数) ，或者对于托管隔离接收位置、后端 Web 服务和 WCF 服务的 ASP.NET Web 应用程序，应修改 (IIS 7.5 和 7.0 集成模式) 并发执行的请求数：

CPU 使用率不是托管 Web 服务器上的瓶颈。
的值：
- ASP.NET Apps v4.0.30319 \Request Wait Time or ASP.NET Apps v4.0.30319 \Request Execution Time 性能计数器异常高。
- ASP.NET 应用 v2.0.50727\请求等待时间 或 ASP.NET 应用 v2.0.50727\请求执行时间 性能计数器异常高。

托管 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 应用程序https://go.microsoft.com/fwlink/?LinkID=144169发出 Web 服务请求时 () 821268争用、性能不佳和死锁。

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

当 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 值

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

警告

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

在 “开始 ”菜单中，找到并启动 “运行 ”提示符，输入 “regedit.exe”，然后选择“ 确定” 以启动注册表编辑器。
导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0
按照以下步骤创建密钥：
1. 在 “编辑” 菜单上，选择“ 新建”，然后选择“ 密钥”。
2. 键入 maxConcurrentRequestsPerCPU，然后按 Enter。
3. 在 maxConcurrentRequestsPerCPU 键下，使用 maxConcurrentRequestsPerCPU 的新值创建 DWORD 条目。
4. 关闭注册表编辑器。

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

下载并安装 Microsoft .NET Framework 3.5 Service Pack 1，这是在配置文件中设置以下值所必需的。完整版本也可用。
打开应用程序池 的aspnet.config 文件。
输入 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 https://go.microsoft.com/fwlink/?LinkId=157518 () ASP.NET 线程使用情况的博客。

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

使用 .NET Framework 4 时，maxConcurrentRequestsPerCPU 的默认设置为 5000，这是一个非常大的数字，因此将允许并发执行大量异步请求。有关详细信息，请参阅 <applicationPool> Element (Web Settings) (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 值

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

警告

在 “开始 ”菜单中，找到并启动 “运行 ”提示符，输入 “regedit.exe”，然后选择“ 确定” 以启动注册表编辑器。
导航到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0。
按照以下步骤创建密钥：
1. 在 “编辑” 菜单上，选择“ 新建”，然后选择“ 密钥”。
2. 键入 maxConcurrentRequestsPerCPU，然后按 Enter。
3. 在 maxConcurrentRequestsPerCPU 键下，使用 maxConcurrentRequestsPerCPU 的新值创建 DWORD 条目。
4. 关闭注册表编辑器。

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

下载并安装 Microsoft .NET Framework 4，这是在配置文件中设置以下值所必需的。
打开应用程序池 的aspnet.config 文件。
为 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 线程池分配足够的线程以防止线程不足。发生线程不足时，没有足够的线程可用于执行对性能产生负面影响的请求工作。同时，应注意防止将线程分配给 the.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 核心而异。

备注

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

线程设置	默认值	建议的值
最大 IO 线程数	250	250
最大工作线程数	25	100 重要提示：将此值增大到超过 100 可能会对托管 BizTalk Server MessageBox 数据库的SQL Server计算机的性能产生不利影响。当发生此问题时，SQL Server 可能会遇到死锁情况。建议不要将此参数增大到超过 100 的值。
最小 IO 线程数	25	25
最小工作线程数	5	25

备注

建议的值不是绝对值，可能需要根据 BizTalk 应用程序进行调整。一次更改一个参数，然后在进行其他更改之前测量对 BizTalk 平台性能和稳定性的影响。

备注

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

禁用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 帮助中的https://go.microsoft.com/fwlink/?LinkID=153814 如何配置 DTA 清除和存档作业 () 。

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

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

安装最新服务包

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

BizTalk Server文档中的性能优化

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

另请参阅

优化 BizTalk Server 性能

通过

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

配置 MSDTC

有关配置BizTalk Server主机的建议

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

配置专用跟踪主机

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

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

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

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

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

在注册表中设置 maxConcurrentRequestsPerCPU 值

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

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

在注册表中设置 maxConcurrentRequestsPerCPU 值

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

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

禁用BizTalk Server组级跟踪

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

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

安装最新服务包

BizTalk Server文档中的性能优化

另请参阅

反馈

其他资源