共用方式為

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

  • 發行項

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

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

應該建立不同的主機來傳送、接收、處理和追蹤功能。 在 BizTalk 群組中設定工作負載時，建立多個 BizTalk 主機可提供彈性，而且是將處理分散到 BizTalk 群組中 BizTalk Server 的主要方式。 多部主機也可讓您停止一部主機，而不會影響其他主機。 例如，您可能想要停止傳送訊息，讓他們在 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已針對輸送量進行優化，因此主要協調流程和傳訊引擎實際上不會直接將訊息移至 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說明中的下列主題：

  • 位於 https://go.microsoft.com/fwlink/?LinkId=101590 的「管理 BAM 事件匯流排服務」。

  • 位於 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 整合模式) ，應該在下列情況下修改：

  • 裝載 Web 服務器上的 CPU 使用率不是瓶頸。

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

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

警告

您需自行承擔使用登錄編輯程式的風險。 不正確的使用可能會導致需要重新安裝作業系統的問題。 如需如何備份、還原及修改登錄的詳細資訊，請參閱 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 執行緒集區配置足夠的執行緒，以避免執行緒不足，是很重要的。 發生執行緒耗盡時，沒有足夠的執行緒可執行對效能造成負面影響的要求工作。 同時，您也必須小心避免配置超出需要的執行緒給與主控件關聯的 .NET 執行緒集區。 將太多執行緒配置給與主機相關聯的 .NET 執行緒集區可能會增加內容切換。 當 Windows 核心從執行一個執行緒切換到不同的執行緒時，就會發生內容切換，這會產生效能成本。 過度的執行緒配置可能會導致過多的內容切換，這會對整體效能造成負面影響。

請在 BizTalk Server 登錄中建立適當的 CLR 裝載值，修改與 BizTalk 主控件執行個體關聯之 .NET 執行緒集區中的可用 Windows 執行緒數目。

警告

不正確使用登錄編輯程式可能會導致您需要重新安裝作業系統的問題。 您必須自行負擔使用「登錄編輯程式」的風險。 For more information about how to back up, restore, and modify the registry, see the Microsoft Knowledge Base article "Description of the Microsoft Windows registry" at 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 安裝，此登錄機碼可能會表示為guidHKEY_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 追蹤資料庫。 如果追蹤不是商務需求，請停用追蹤以減少額外負荷並提升效能。 For more information about configuring tracking, see “Configuring Tracking Using the BizTalk Server Administration Console” in the BizTalk Server help at https://go.microsoft.com/fwlink/?LinkID=106742.

在高輸送量案例中，將 DTA 清除和封存作業的清除期間從 7 天減少到 2 天

根據預設，BizTalk Server中追蹤資料的清除間隔會設定為 7 天。 在高輸送量案例中，這可能會導致追蹤資料庫中的資料過度建置，這最終會影響 MessageBox 的效能，進而對訊息處理輸送量造成負面影響。

在高輸送量案例中，將預設的硬式和軟清除間隔從 7 天縮減為 2 天。 For more information about configuring the purging interval, see “How to Configure the DTA Purge and Archive Job” in the BizTalk Server help at https://go.microsoft.com/fwlink/?LinkID=104908.

安裝最新的 Service Pack

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

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

雖然 BizTalk Server 2006 和後續版本的 BizTalk Server 可讓您將 BizTalk 主機設定為叢集資源，但如果您需要為無法跨多個 BizTalk 電腦裝載的資源提供高可用性，就應該考慮這麼做。 例如，使用 FTP 介面卡的埠應該只位於一個主機實例上，因為 FTP 通訊協定不提供檔案鎖定，不過，這引進了單一失敗點，這可受益于叢集。 包含介面卡的主機，例如檔案、SQL、HTTP 或僅處理主機，可以在機器內部進行負載平衡，而且無法受益于叢集。

BizTalk Server檔中的效能優化

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