BizTalk Server的一般優化 - 第 1 部分

發行項
10/04/2023

下列建議可用來增加BizTalk Server效能。本主題中列出的優化會在安裝及設定BizTalk Server之後套用。

設定 MSDTC

若要協助SQL Server與BizTalk Server之間的交易，您必須啟用 Microsoft Distributed Transaction Coordinator (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 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 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 配接器，) 只開啟執行BizTalk Server至任何特定目的地伺服器的每部電腦兩個並行 HTTP 連線。

此設定符合 HTTP 1.1 規格的 IETF RFC，雖然它適用于使用者案例，但它並未針對高輸送量進行優化。此設定會有效地將每部伺服器的輸出 HTTP 呼叫節流至從執行BizTalk Server的每部電腦傳送兩個並行傳送。

若要增加並行連線數目，您可以在每個BizTalk Server上修改 BizTalk Server 組態檔中 maxconnection 參數的值，BTSNTSvc.exe.config (或 BTSNTSvc64.exe.config 64 位) 主機 BTSNTSvc64.exe.config。您可以針對所呼叫的特定伺服器增加此功能。根據經驗法則，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" />

For more information about tuning IIS and ASP.NET settings for Web services, see the "ASP.NET settings that can impact HTTP Adapter performance" section of Configuration Parameters that Affect Adapter Performance (https://go.microsoft.com/fwlink/?LinkID=154200) in BizTalk Server 2010 Help.

管理 ASP.NET 執行緒使用量，或同時執行可裝載隔離接收位置、後端 Web 服務和 WCF 服務的 Web 應用程式要求

傳統模式中的背景工作角色和 I/O 執行緒數目 (IIS 7.5 和 IIS 7.0) 或同時執行的要求數目， (IIS 7.5 和 7.0 整合模式) 裝載隔離接收位置、後端 Web 服務和 WCF 服務的 ASP.NET Web 應用程式，應該在下列情況下修改：

裝載 Web 服務器上的 CPU 使用率不是瓶頸。
的值：
- 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) 。

管理在 IIS 7.5 和 IIS 7.0 上以整合模式執行的 ASP.NET 2.0 Web 應用程式同時執行的要求數目，這些應用程式可以裝載隔離接收的位置、後端 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 值

此設定為全域設定，無法變更個別應用程式集區或應用程式。

警告

您需自行承擔使用登錄編輯程式的風險。不正確的使用可能會導致需要重新安裝作業系統的問題。如需如何備份、還原及修改登錄的詳細資訊，請參閱 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 () 上 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 值

此設定為全域設定，無法變更個別應用程式集區或應用程式。

警告

從 [ 開始] 功能表中，尋找並啟動 [ 執行 ] 提示字元，輸入 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 執行緒集區配置足夠的執行緒，以避免執行緒不足，是很重要的。發生執行緒耗盡時，沒有足夠的執行緒可執行對效能造成負面影響的要求工作。同時，您也必須小心避免配置超出需要的執行緒給與主控件關聯的 .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 說明中的How to Configure the DTA Purge and Archive Job (https://go.microsoft.com/fwlink/?LinkID=153814) 。

設定 BizTalk 服務帳戶的 %temp% 路徑，以指向不同的磁片或 LUN

這應該完成，因為 BizTalk 會在執行複雜的對應作業時，使用暫存位置將檔案串流至磁片。

安裝最新的 Service Pack

應該安裝適用于BizTalk Server和.NET Framework的最新 Service Pack，因為這些 Service Pack 包含可修正您可能會遇到的效能問題。

BizTalk Server檔中的效能優化

視需要從BizTalk Server檔套用下列建議：

另請參閱

最佳化 BizTalk Server 效能

共用方式為

BizTalk Server的一般優化 - 第 1 部分

設定 MSDTC

設定BizTalk Server主機的建議

依功能建立多個BizTalk Server主機和個別主機實例

設定專用追蹤主機

除非絕對必要，否則請勿叢集 BizTalk 主機

變更 maxconnection 參數的值，以增加允許的 HTTP 並行連線數目

管理 ASP.NET 執行緒使用量，或同時執行可裝載隔離接收位置、後端 Web 服務和 WCF 服務的 Web 應用程式要求

管理可裝載在傳統模式中執行之 IIS 7.5 和 IIS 7.0 上隔離接收位置、後端 Web 服務和 WCF 服務的 Web 應用程式 ASP.NET 執行緒使用量

管理在 IIS 7.5 和 IIS 7.0 上以整合模式執行的 ASP.NET 2.0 Web 應用程式同時執行的要求數目，這些應用程式可以裝載隔離接收的位置、後端 Web 服務和 WCF 服務

在登錄中設定 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

安裝最新的 Service Pack

BizTalk Server檔中的效能優化

另請參閱

意見反應

其他資源