訊息考量
BizTalk Server提供一組廣泛的功能，可用來傳送、接收、轉換和處理訊息。 其中一些功能包含：
能夠使用多個業界標準傳輸來傳送和接收訊息，例如 HTTP、SMTP、FTP/FTPS 和 WCF。 使用BizTalk Server配接器來完成傳送和接收訊息的傳輸層級支援。 BizTalk Server訊息處理與各種「企業營運」 (LOB) 應用程式整合是使用許多可用的BizTalk Server加速器或配接器之一來完成，例如 BizTalk Accelerator for HIPAA、BizTalk Accelerator for SWIFT 或 BizTalk SAP 配接器。 這些加速器和介面卡符合業界標準，進而配合直接整合BizTalk Server與符合特定業界標準的系統。
能夠處理多個訊息格式，例如純文字、XML、二進位和其他格式。 這項功能對於提供與各種交易夥伴的BizTalk Server整合非常重要。
支援訊息轉換或檔對應。 對應可容納不同架構之間的資料轉換。 例如，對應可用來將已接收的客戶採購單內容轉換成收據，並傳送出貨通知給客戶。
BizTalk Server協調流程提供功能來建立跨越時間、組織、應用程式和人員的商務程式。 BizTalk Server提供協調流程Designer圖形化介面來開發商務程式，包括支援傳統「不可部分完成」MSDTC 類型和長時間執行 () 、例外狀況處理、偵錯、追蹤和呼叫外部程式碼的擴充性。
注意
如需在 BizTalk Server 中使用協調流程時所遵循的最佳做法指引，請參閱優化協調流程效能。 如需使用協調流程Designer的詳細資訊，請參閱BizTalk Server檔中的建立協調流程Designer (https://go.microsoft.com/fwlink/?LinkId=158997) 主題。
本主題的其餘部分說明與BizTalk Server環境中處理之訊息的大小、複雜度和散發設定檔相關的效能考慮。
訊息大小考慮
雖然BizTalk Server對訊息大小沒有限制，但實際限制和相依性可能需要您將訊息的大小降到最低，因為大型訊息需要更多處理資源。 隨著訊息大小增加，每秒處理的訊息 (整體輸送量) 減少。 設計案例並規劃容量時，請考慮BizTalk Server處理常式的平均訊息大小、訊息類型和訊息數目。 請勿使用不必要的長屬性和標記名稱;可能的話，請保留長度低於 50 個字元。 例如，請勿將 200 個字元的標記名稱用於訊息大小只有 1 個位元組。
如果所接收訊息的記憶體內部大小超過針對 [大型訊息片段大小] 指定的位元組數目， (可在 BizTalk Server 管理主控台中 BizTalk 群組的 [群組屬性] 頁面上設定) ，訊息會分割成指定大小的片段。 此外，片段會寫入 Microsoft 分散式交易協調器內容下的 Messagebox， (MSDTC) 交易，如下所示：
如果在現有 MSDTC 交易的內容中發佈傳入訊息，則會在將訊息片段寫入 BizTalk MessageBox 資料庫時使用此交易。 例如，如果傳入訊息是由設定為需要交易的交易配接器所發佈，則會在將訊息片段寫入 MessageBox 資料庫時使用現有的交易。
如果傳入訊息未在現有 MSDTC 交易的內容中發佈，則會建立新的 MSDTC 交易，以將訊息片段寫入 MessageBox 資料庫。 在此案例中，適用下列考慮：
增加 大型訊息片段大小 的值，以減少大型訊息分散的頻率，並減少建立相關聯 MSDTC 交易的發生頻率。 您應該執行此動作，因為從效能觀點來看，過度使用 MSDTC 交易的代價很高。 請注意，增加此值也可能增加使用的可用記憶體量。
如果超過 60 分鐘允許的 MSDTC 交易逾時上限，將訊息寫入 MessageBox 時，交易逾時、發生錯誤，且嘗試寫入訊息失敗並回復。 處理非常大的訊息時，應該增加大型訊息片段大小值，以避免這個問題。 視可用的記憶體而定，此值最多可增加到 1000000 個位元組的值。
訊息中的每個訊息分割都會對 MessageBox 資料庫建立一或多個 SQL Server 資料庫鎖定。 當鎖定數目超過數百萬時，SQL Server可能會產生「鎖定不足」錯誤。 如果發生此問題，請增加大型訊息片段大小的值，以減少 (的片段數目，以減少針對 MessageBox 資料庫所做的SQL Server資料庫鎖定數目) ，或考慮在 64 位版本的 SQL Server 上儲存您的 MessageBox 資料庫。 SQL Server 64 位版本的可用鎖定數目明顯高於 32 位版本的 SQL Server。 當 MessageBox 資料庫位於 32 位版本的 SQL Server 時，下列公式可用來估計每個交換的最大訊息數目：
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
如需BizTalk Server處理大型訊息的詳細資訊，包括處理大型訊息的指導方針，請參閱BizTalk Server如何處理大型訊息 (https://go.microsoft.com/fwlink/?LinkID=154680) 。
訊息類型考慮
訊息會以兩種主要格式的其中一種接收至BizTalk Server：XML 檔案或一般檔案。 由於 XML 和一般檔案訊息的不同資源需求，訊息類型應該一律納入訊息散發設定檔中。
XML 檔案為了讓BizTalk Server在傳遞路由以外的訊息上執行任何處理，訊息必須是 XML 檔案格式。
一般檔案一般檔案必須剖析成 XML 格式，BizTalk Server才能執行傳遞路由以外的任何處理。 將一般檔案剖析為 XML 檔案會大幅增加檔案大小。 一般檔案不包含 XML 標記及其資料的描述性資訊。 另一方面，XML 檔案會將所有資料包裝在描述性 XML 標記中。 在某些情況下，剖析可能會根據檔案的 XML 標籤中包含多少描述性資料，以 10 或更多因素增加一般檔案的大小。
XML 檔中單一 CDATA 區段節點中包裝的一般檔案檔這種類型的檔是 XML 和一般檔案的組合，而且經常需要大量記憶體，因為BizTalk Server必須先將整個包裝的一般檔案檔載入記憶體，才能處理它。
多載考慮
大部分BizTalk Server應用程式不會以特定的固定速率接收訊息。 一般而言，訊息處理受限於尖峰和矽谷。 例如，線上銀行應用程式可能會先在早上處理大量的訊息，然後在當天中間，以及一天結束時。 BizTalk Server解決方案應經過測試，以確保它們能夠處理這些多載案例。 若要判斷BizTalk Server解決方案處理多載案例的方式，應該判斷BizTalk Server解決方案 (MST) 的最大持續性輸送量。 MST 是系統可以在生產環境中無限期處理的最大訊息流量負載。 如需 MST 的詳細資訊，請參閱BizTalk Server檔中規劃持續效能 (https://go.microsoft.com/fwlink/?LinkID=158065) 和什麼是永續性效能？ (https://go.microsoft.com/fwlink/?LinkID=132304) 。
架構複雜度
訊息剖析的輸送量 (特別是一般檔案剖析) 會受到架構的複雜度影響。 當架構複雜度增加時，整體效能會降低。 設計架構時，請減少節點名稱的長度，並將升級的屬性移至架構頂端。 這可減少擷取時間，進而提升效能。
對應複雜度
根據地圖的複雜度，地圖轉換可能會耗用大量資源。 隨著地圖複雜度增加，整體效能會降低。 若要改善整體效能，請將地圖中使用的連結和運算質數目降到最低，特別是呼叫資料庫查閱運算質等外部資源的運算質。
一般檔案剖析考慮
對一般檔案剖析效能有最高影響的兩個因素是檔案大小和架構複雜度。 模棱兩可的架構是包含許多選擇性欄位的架構。 使用大型檔案大小時，具有許多選擇性欄位的架構可能會降低效能，因為較大的檔案可能會符合架構的不同分支。 架構複雜度對較小的檔案的影響比較大的檔案少。