識別 BizTalk 層中的瓶頸
BizTalk 層可以區分為下列功能區域：
接收
處理
傳輸
追蹤
其他
對於這些區域，如果系統資源 (CPU、記憶體和磁碟) 看來已經飽和，則藉由向上擴充來升級伺服器。 如果系統資源尚未飽和，請執行在此節中描述的步驟。
接收位置中的瓶頸
如果訊息開始在接受位置累積 (例如，檔案接收資料夾變得很大或輸出佇列無法很快耗盡)，即代表內部的節流導致系統吸收資料的速率不夠快，無法跟上內送負荷 (如果訂閱者處理資料的速度不夠快，而導致資料庫資料表中開始累積待處理的項目，BizTalk 就會降低接收速率)。 如果瓶頸是由於硬體限制而造成，請嘗試向上擴充硬體。 也可以藉由將「主控件執行個體」(伺服器) 新增至對應到接收處理常式的「主控件」來向外擴充。 使用 Perfmon 來監視系統上的資源利用。 確認外部的接收位置並非瓶頸肇因，這點很重要。 例如，遠端的檔案共用由於高磁碟 IO 速度而飽和，或者裝載遠端外寄佇列的伺服器並未飽和，或者用來產生 HTTP/SOAP 負載的用戶端尚未用完執行緒。
處理瓶頸
如果主機佇列 - 長度計數 (看到下方的 Perfmon 計數器數據表) 正在提升，表示協調流程的速度不夠快。 這可能是由於記憶體爭用或 CPU 飽和而導致。
如果協調流程伺服器是瓶頸所在，請使用 Perfmon 以識別來源。
如果伺服器受限於 CPU 處理能力，請考慮下列各項：
如果工作流程很複雜，可考慮將協調流程切割為多個較小的協調流程
注意
將協調流程切割為多個工作流程，可能會導致額外的延遲狀況，並增加複雜度。
如果有使用複雜的對應，請考慮是否可將這些對應移至接收埠/傳送埠 (請確認這些埠是否有額外的頻寬)。
請考慮向上擴充硬體，或者如有可能，請考慮藉由設定額外的處理伺服器來向外擴充。
傳輸瓶頸
如果傳輸伺服器的資源使用已經飽和 (例如，磁碟、記憶體、CPU)，請考慮向上擴充伺服器，或者如有可能，請考慮向外擴充到其他的傳送主機伺服器。 如果目的地 (在 BizTalk 外部) 無法以夠快的速率接收資料，則傳送層可能會成為瓶頸。 這會導致訊息在 MessageBox 資料庫 (Application SendHostQ) 中累積。
如果端點位於拓撲的範圍內，請考慮在目的地導致累積的原因。 例如，HTTP/SOAP 位置的設定是否對接收負載進行過最佳化，或者是否可以向外擴展？ 如果目的地的成長是由於 BizTalk 傳遞的輸出訊息過多而造成？ 如果答案為真，請考慮施行維護計畫，以封存及清除目的地訊息。 例如，目的資料夾中若含有大量檔案，可能會嚴重影響 BizTalk 服務將資料認可到磁碟機的能力。
追蹤瓶頸
追蹤主機實例負責將 BAM & 追蹤的訊息事件和服務實例數據從 MessageBox 資料庫 (TrackingData 數據表) 移至 BizTalkDTADb 和/或 BAMPrimaryImport 資料庫數據表。 如果設定多個 MessageBox 資料庫，則追蹤主控件執行個體會針對每個 MessageBox 使用四個執行緒。
這個主控件執行個體有可能會變成受限於 CPU 處理能力。 如果是這種情況，請考慮向上擴充伺服器，或者設定啟用「主控件追蹤」的其他伺服器來向外擴充。 多重主控件執行個體會自動針對設定的多個 MessageBoxes 進行平衡負載。
如果 MessageBox 資料庫中的 TrackingData 資料表開始累積，通常是因為 BizTalkDTADb 和 (或) BAMPrimaryImport y 資料庫上的資料維護工作未依照設定執行，導致 BizTalkDTADb 和 (或) BAMPrimaryImport 資料庫成長。 資料庫一旦過度成長，就可能會對追蹤主控件將資料插入這些資料表的能力造成負面影響，導致追蹤資料在 MessageBox 資料庫資料表中累積。 MessageBox-TrackingData> 數據表的成長會導致節流開始。
其他
設定部署拓撲，使不同的功能可在專用的外掛式主控件執行個體中執行。 如此，每個主控件執行個體都可取得自己的資源集 (在 32 位元的系統上，可享有 2GB 的虛擬記憶體位址空間、控制代碼、執行緒等)。 如果伺服器有足夠的資源 (足夠的 CUP 空間、記憶體) 來裝載多個主控件執行個體，可以將這些執行個體設定為在相同的實體電腦上執行。 如果沒有，這麼做也可以將功能移至專用的伺服器，而簡化向外擴充的作業。 在多個伺服器上執行相同的功能，也可以提供具有高度可用性的組態。
BizTalk 系統效能計數器
| Object | 執行個體 | 計數器 | 監控目的 |
|---|---|---|---|
| 處理器 | _Total | % Processor Time | 資源爭用 |
| 流程 | BTSNTSvc | 虛擬位元組 | 記憶體流失/膨脹 |
| 流程 | BTSNTSvc | 私用位元組 | 記憶體流失/膨脹 |
| 流程 | BTSNTSvc | 控制代碼計數 | 資源爭用 |
| 流程 | BTSNTSvc | 執行緒計數 | 資源爭用 |
| Physical Disk | _Total | % Idle Time | 資源爭用 |
| Physical Disk | _Total | Current Disk Queue Length | 資源爭用 |
CPU 爭用
如果處理器已飽和，請考慮將接收從傳送和協調流程分隔，以分割應用程式。 完成這項作業的方法為建立分隔的主控件、將這些主控件對應到特定的功能 (接收/傳送/協調流程/追蹤)，然後將專用的伺服器新增至這些分隔的主控件。 一般而言，協調流程功能是很耗費 CPU 的，所以將系統設定為在分隔的專用伺服器上執行協調流程，有助於改善整體系統的輸送量。
如果要部署多個協調流程，可以將這些協調流程登錄到不同的專用協調流程主控件。 將不同的實體伺服器對應到專用的協調流程主控件，可確保不同的協調流程均已隔離，而不會爭用相同實體位置空間或相同伺服器的共用資源。
記憶體耗盡
高輸送量實例可能增加對系統記體體的需求。 由於 32 位元的程序受限於它可以消耗的記憶體量，所以建議將接收/程序/傳送等功能分隔到個別的主控件執行個體中，使每個主控件都能接收自己的 2GB 位址空間。 此外，如果在相同的實體伺服器上執行多個主控件執行個體，則升級到 4/8GB 記憶體可避免將資料從實際的記憶體磁碟交換到磁碟，是很有用的作法。 長時間執行的協調流程可能會保留已配置的記憶體較長，因而造成記憶體不足，因此節流會啟動。 大型訊息也可能造成高記憶體耗用量。
當大型訊息正在處理時，可能會降低特定主機的每個 CPU 值 的內部訊息佇列大小 和 進程訊息 ，以克服此記憶體不足的問題。
磁碟爭用
例如，如果磁碟已飽和 (，檔案/MSMQ 傳輸) 請考慮升級至多個軸，並使用RAID 1+0等量磁碟。 此外，每當使用 FILE 傳輸時，請務必確保接收和傳送 () 的資料夾不會成長太大 >， (50,000 個檔案) 。
如果由於下面所述的各種原因，BizTalk Server 選擇對內送到系統中的資料進行節流，接收資料夾就可能變得很大。 從傳送資料夾移動資料很重要，因為這麼做這個資料夾的成長就不會影響 BizTalk Server 寫入其他資料的能力。 對於非交易式的 MSMQ 佇列而言，則建議在遠端建立接收佇列，以減輕 BizTalk Server 上的磁碟爭用情況。
這項組態 (遠端非交易式佇列) 也提供高可用性的額外優點，因為裝載佇列的遠端伺服器可以叢集化。
其他系統資源爭用
根據所設定的傳輸本質，可能有必要針對 HTTP/SOAP 設定 IIS 之類的系統資源 (例如，MaxIOThreads、MaxWorkerThreads)。
下游瓶頸
如果下游系統無法以夠快的速度從 BizTalk 接收資料，這些輸出資料就會在 BizTalk 資料庫中累積而導致膨脹，促使節流開始作用，使接收管道壓縮，因此對 BizTalk 系統的整體輸送量造成衝擊。 這種現象的直接代表就是多工緩衝成長。
節流衝擊
節流最終會開始作用，以保護系統不致達到不可復原的狀態。 因此，節流是驗證系統是否正常運作並探索問題來源的好方法。 從節流狀態識別出瓶頸的原因後，可分析其他的效能計數器以向下切入問題的來源。
例如，在 MessageBox 資料庫上的高爭用情況可能是由於高 CPU 使用量造成，高 CPU 使用量可能是由於磁碟過度分頁造成，過度分頁又可能是由於記憶體不足的情況而導致。 在 MessageBox 資料庫上的高度爭用情況也可能是由於高度鎖定爭用而造成，鎖定爭用則可能是由於磁碟機飽和而導致。
BizTalk 應用程式計數器
| Object | 執行個體 | 計數器 | 描述 |
|---|---|---|---|
| BizTalk 傳訊 | RxHost | 每秒接收文件數 | 內送速率 |
| BizTalk 傳訊 | TxHost | 每秒處理文件數 | 外寄速率 |
| XLANG/s 協調流程 | PxHost | 每秒完成的協調流程數 | 處理速度 |
| BizTalk：MessageBox：一般計數器 | MsgBoxName | 多工緩衝處理大小 | 所有主控件佇列總計大小 |
| BizTalk：MessageBox：一般計數器 | MsgBoxName | 追蹤資料大小 | MessageBox 上的 TrackingData 資料表大小 |
| BizTalk：MessageBox：主控件計數器 | PxHost:MsgBoxName | 主控件佇列 - 長度 | 指定主控件佇列中的訊息數 |
| BizTalk：MessageBox：主控件計數器 | TxHost:MsgBoxName | 主控件佇列 - 長度 | 指定主控件佇列中的訊息數 |
| BizTalk：訊息代理程式 | RxHost | 資料庫大小 | 發佈 (PxHost) 佇列的大小 |
| BizTalk：訊息代理程式 | PxHost | 資料庫大小 | 發佈 (TxHost) 佇列的大小 |
| BizTalk：訊息代理程式 | HostName | 訊息傳遞節流狀態 | 影響 XLANG 和輸出傳輸 |
| BizTalk：訊息代理程式 | HostName | 訊息發佈節流狀態 | 影響 XLANG 和輸入傳輸 |
我該從哪裡開始？
監視每個主機實例的 訊息傳遞節流狀態 和 訊息發佈節流狀態 通常是開始的好位置。 如果這些計數器的值並非零，則代表節流正在 BizTalk 系統中進行，有可能可以進一步分析瓶頸的原因。 如需其他性能計數器的描述，請參閱 識別效能瓶頸。
待處理項目積存
在 1 對 1 的部署實例中 (也就是接收 1 個訊息會導致處理及傳輸 1 個訊息)，如果外寄速率不等於內送速率，則會在系統中的某一處積存待處理的項目。 在發生這種情況時，可以監控多工緩衝處理大小。
如果多工緩衝處理是以線性成長，則可以藉由確認負責多工緩衝處理成長的應用程式佇列來進一步向下切入。
如果沒有任何應用程式佇列有成長，多工緩衝處理卻持續成長，就可能代表由於代理程式未在執行或者 SQL 伺服器上有其他的系統資源爭用情況，而導致清除工作無法跟上成長速度。
如果其中有一個應用程式佇列在成長，則診斷這項成長的原因很重要。 請在無法清空特定應用程式佇列的系統上監控系統資源 (例如，Orchestration Host-Q 會由於伺服器上的 CPU 耗盡而成長)。 此外，請針對特定主控件執行個體而確認節流計數器的值。
如果傳遞/發佈狀態並非零，請檢查該值以確認節流的原因 (例如，已超過記憶體閾值、傳遞訊息計數過高等等)。
F1 Profiler
藉由使用效能計數器，可以快速地在高層級偵測到瓶頸的位置。 不過，一旦將範圍縮小，就可能必須進一步向下切入到節點中，才有助於減輕問題。 附隨於 Visual Studio 的 F1 Profiler 可能是一項非常有用的工具，有助於診斷程式碼將大多數的循環花在何處。
若要建立更有意義的堆疊，則符號很重要 (特別對於 Unmanaged 程式碼而言)。 例如，F1-Profiler 有助於找出叫用的次數，以及傳回 API 呼叫的時間量。 在堆疊中更向下切入，就可能可以偵測到高延遲狀況的原因。 這可能是對資料庫查詢的封鎖呼叫，或只是等候事件的呼叫。
L2/L3 快取
最大的優點 (從硬體觀點來看)，是可以利用內建的 CPU 快取。 較高的 CPU 快取有助於增加快取命中率，減少系統從記憶體對磁碟進行來回資料分頁的需求。
64 位元效能瓶頸
64 位元系統上的效能可能看來會低於在 32 位元系統上所能達到的效能。 這種現象可能會因為數項原因而造成，其中最主要的原因就是記憶體。
評估具有 2GB 記憶體的 32 位元系統效能，然後將結果與具有 2GB 記憶體的 64 位元系統所能達到的效能進行比較，並不是一項公平的的比較。 64 位元的系統看起來較受限於磁碟 IO 的處理能力 (低 % 磁碟閒置時間 & 高磁碟佇列長度) 和 CPU 的處理能力 (CPU 上限 & 高內容切換)。 不過，這並不是因為在 64 位元系統上執行檔案 IO 較耗費資源。
64 位元系統較耗費記憶體 (64 位元定位)，這會導致 OS 耗用大部分的 2GB 可用記憶體。 一旦發生這種情況，大部分的其他作業都會讓分頁進入磁碟，進而影響檔案子系統。 現在系統不單會將 CPU 循環花在將資料和程式碼來回分頁到記憶體上，也會受到高磁碟延遲的影響。 這會造成系統呈現較高磁碟爭用和較高 CPU 耗用的情況。
減輕這項問題的方式是升級記憶體 (理想狀況下 8GB)，以向上擴充伺服器。 不過，加入更多的記憶體對改善輸送量並無助益，除非問題的來源是因為記憶體不足而導致 CPU 耗盡。
使用 BAM 識別瓶頸和高延遲問題
如果是在很需要低延遲的情況中，可以使用 BAM 來評估系統完成 BizTalk 系統內每個階段所需的時間。 雖然追蹤的訊息事件和服務實例數據可用來偵錯訊息的狀態，並診斷路由訊息中的問題來源，但 BAM 可用來透過訊息流程追蹤各種點。 藉由建立 BAM 追蹤設定檔 (以接續來定義活動)，您可以評估系統不同部分之間的延遲，以協助追蹤工作流程程序內最耗費資源的階段。