測試引擎效能時的建議
在測試 BizTalk 引擎效能時，應該遵循下列指導方針：
瞭解負載行為設定檔 如三個負載測試所說明，請務必知道負載的設定檔，以經過一段時間處理的訊息。 您越瞭解這點，就能越正確地測試和調整您的系統容量。 若您只知道峰值傳輸量需求，則最保險的方式就是調整您的系統大小，使可持續的傳輸量上限大於或等於您的峰值負載。 不過，若您可預測負載的峰值與谷值，可以將系統大小的最佳值調整在峰值之間，這樣能有較低且較少的整體部署成本。
提早測試效能 請避免投入大量精力來設計和測試解決方案的功能，但等到最後一分鐘才測試生產硬體上的效能。 請盡早在您的開發週期中，於模擬預期負載設定檔的系統上，執行效能測試。 若您必須變更任何的設計或結構來完成您的目標，能越早知道必須這樣做，便能有越充裕的時間去進行調整和再次測試。
在測試效能時模擬預期的負載設定檔 此專案有兩個主要元件：
模擬某段時間的負載設定檔。
執行測試的時間夠久才能評估是否有持續性。
一般來說，若您的週期為每日時，您至少應該規劃執行一天的效能測試，以驗證其持續性。 執行測試的時間越久越好。
模擬生產設定 例如，埠的數目和類型、主機和主機實例組態、資料庫組態和配接器設定。 請勿假設組態變更不會嚴重影響效能。
使用實際訊息 訊息大小和訊息複雜度會影響效能，因此請確定並使用您打算在生產環境中查看的相同訊息架構和實例進行測試。
在效能測試期間模擬您的正常作業 雖然負載測試不包含它們，但定期資料庫查詢、備份和清除等標準作業活動會影響您的永續性輸送量，因此請確定您在效能和容量測試回合期間執行這些工作。 若您計畫在產品中使用到 DTA 和 BAM 追蹤時，請加入它們。
MessageBox 的 I/O 子系統速度是關鍵成功因素 針對此建置專用的 MessageBox 資料庫檔案，使用快速儲存區域網路所執行的負載測試。即使在這種情況中，清除作業仍能夠讓 SQL 資料檔案的閒置時間接近零。 生產系統中的 I/O 子系統經常是瓶頸的所在。 常用的最佳化 SQL I/O 策略就是在個別的實體磁碟機上放置資料檔與記錄檔 (若可行的話)。
確定 SQL Agent 已在所有 MessageBox 伺服器上執行 很明顯地，如果 SQL Agent 未執行，清除作業永遠不會執行，因此請確定這些作業正在執行。
多工緩衝處理深度是關鍵指標 不論其他指標為何，此量值都會讓您快速且輕鬆地評估系統是否過度驅動。