測試 BizTalk 引擎效能時應遵循以下指引：
了解你的負載行為設定 正如三次負載測試所示，了解負載隨時間處理的訊息分布非常重要。 你越了解這點，就能越準確地測試和調整系統容量。 如果你只知道峰值吞吐量需求，最保守的做法是將系統規模調整到最大可持續吞吐量與峰值負載相同或更高。 然而，如果你知道負載有可預測的高峰與低谷，就能更好地優化系統在高峰間的復原，從而使整體部署更小且成本更低。
測試初期表現 避免陷入那種在設計與測試解決方案功能上投入大量心力，卻拖到最後一刻才在生產硬體上測試效能的陷阱。 在開發週期中盡可能早地對系統進行效能測試，模擬預期的負載狀況。 如果你為了達成目標必須改變設計或架構，早點知道這點會給你時間調整和再次測試。
模擬你預期的負載配置來測試效能 這主要有兩個要素：
隨時間模擬負載曲線。
先做夠久的測試，評估是否可持續。
如果你的週期通常是每日進行的，你應該計劃至少執行一天的性能測試，以驗證永續性。 你做測試的時間越長越好。
模擬生產配置 例如，埠的數量與類型、主機與主機實例的設定、資料庫設定，以及適配器的設定。 不要以為設定變更不會對效能有重大影響。
使用真實訊息 訊息大小和訊息複雜度會影響效能，所以務必用你打算在生產環境中看到的相同訊息結構和實例來測試。
模擬你在效能測試時的正常操作 雖然負載測試未包含這些任務，但標準作業活動如定期資料庫查詢、備份與清除，會影響您的永續吞吐量，因此務必在效能與容量測試執行時執行這些任務。 這包括 DTA 和 BAM 追蹤，如果你打算在生產環境中使用它們。
MessageBox 輸入/輸出子系統的速度是成功的關鍵因素 所執行的負載測試利用了專用於此建置的 MessageBox 資料庫檔案的快速儲存區域網路（Storage Area Network）。即使如此，清理工作仍能將 SQL 資料檔案的閒置時間接近零。 輸入輸出子系統在生產系統中經常成為瓶頸。 優化 SQL I/O 的常見策略是盡可能將資料庫資料檔案與日誌檔案分別放在實體硬碟上。
確保 SQL 代理程式在所有 MessageBox 伺服器上都運行 很明顯，如果 SQL 代理程式沒在執行，清理工作永遠不會執行，所以一定要確保這些工作都在執行。
線軸深度是關鍵指標 不論其他指標如何，這項指標都能讓你快速且簡便地評估系統是否被過度驅動。