調查瓶頸

本主題描述調查瓶頸的建議程式。

問題的來源為何？

瓶頸的來源可能是硬體或軟體相關。 當資源使用量過低時，通常是瓶頸的指示。 瓶頸可能是因為硬體限制、沒有效率的軟體組態或兩者而造成。

識別瓶頸是一項遞增程序，解決一個瓶頸，可能導致下一個瓶頸被發現。 識別和解決瓶頸的技術是本主題的目標。 系統在短時間內處於尖峰執行狀態，這種情形有可能發生。 不過，對持續性輸送量來說，系統最快只能用其最慢執行元件的速度處理。

使用反復測試方法

瓶頸可能發生在系統 (進入/結束) 的端點或中間 (協調流程/資料庫) 。 隔離瓶頸之後，請使用結構化方法來識別來源。 緩和瓶頸之後，請務必再次測量效能，以確保系統其他位置尚未引進新的瓶頸。

識別和修正瓶頸的程式應該以反復的方式完成。 一次只變更一個參數，在每個測試回合期間重複完全相同的步驟，然後測量效能來驗證單一修改的影響。 同時變動多個參數可能會掩蓋此變更的作用。

例如，變更參數 1 可以改善效能。 不過，將參數 2 與變更參數 1 搭配變更可能會造成負面影響，並否定變更參數 1 的優點。 這會導致淨零效果，並對不同參數 1 的效果產生誤判，而對不同參數 2 的效果產生誤判。

測試一致性

應該在變更設定之後測量效能特性，以驗證變更的效果。

• 硬體- 使用一致的硬體，因為不同的硬體可能會導致不一致的行為，並產生誤導的結果。 例如，您不會使用膝上型電腦來測試 BizTalk 解決方案的效能。

• 測試回合持續時間 - 測量固定最小期間的效能，以確保結果持續存在。 長時間執行測試也可確保系統在達到預先定義的臨界值之後，已通過初始暖/加速期間，其中所有快取都已填入、資料庫資料表已達到預期的計數，而且節流已有足夠的時間來規範輸送量。 這種方法有助於探索最佳、持續性輸送量。

• 測試參數 – 請勿將測試參數從測試回合變更為測試回合。 例如，變更對應的複雜性和 (或) 文件大小，可能會產生不同的輸送量和延遲結果。

• 清除狀態 - 測試完成之後，請先確定測試環境的狀態是乾淨狀態，再執行下一個測試。 例如，歷程記錄資料可以在影響執行時間輸送量的資料庫中建置。 回收服務實例有助於釋放快取的資源，例如記憶體、資料庫連結和執行緒。 在測試環境中，您可能會想要建立和執行bts_CleanupMsgbox預存程式，如 如何在測試環境中https://go.microsoft.com/fwlink/?LinkId=158064 手動清除 MessageBox 資料庫中的資料 () 中所述。 此腳本旨在將您的BizTalk Server測試環境傳回與執行之間訊息方塊相關的全新狀態。 腳本會刪除所有執行中的實例，以及這些實例的所有相關資訊，包括狀態、訊息和訂用帳戶，但會離開所有啟用訂用帳戶，因此您不需要重新登記協調流程或傳送埠。 請注意，生產系統不支援此工具。

• 效能測試和微調 - 此測試類別的目標是將應用程式的效能和輸送量最大化，並尋找系統的 MST (最大持續性輸送量) 。 如需規劃和測量最大持續性效能的詳細資訊，請參閱 規劃持續效能 () https://go.microsoft.com/fwlink/?LinkId=158065 和 什麼是永續性效能？ (https://go.microsoft.com/fwlink/?LinkId=132304) 。

  MST 是系統可以在生產環境中無限期處理的最大訊息流量負載。 所有 BizTalk 應用程式都應該先測試效能和輸送量，再進入生產環境。 您至少應該執行一組代表最常見的使用案例的測試案例。 建議您在符合生產環境特性的個別環境中，針對預期的負載和尖峰負載進行測試。 此環境應該已安裝並執行所有公司標準服務，例如監視代理程式和防毒軟體。

• 我們也建議您在生產環境中相同的硬體上測試新的 BizTalk 應用程式，以及正在執行的其他 BizTalk 應用程式。 這些其他 BizTalk 應用程式會將額外的負載放在BizTalk Server、SQL Server、網路 I/O 和磁片 I/O 上。 此外，一個 BizTalk 應用程式可能會讓另一個應用程式在多工緩衝處理深度太大時進行節流 (，例如) 。 所有 BizTalk 應用程式都應該在進入生產環境之前經過效能/壓力測試。 此外，您應該判斷系統從尖峰負載復原所需的時間。 如果系統不會在發生下一個尖峰負載之前完全從尖峰負載復原，則發生問題。 系統會更進一步且更進一步地落後，且永遠不會完全復原。

預期：輸送量與延遲

您可以預期已部署系統的輸送量和/或延遲量。 嘗試達到高輸送量和低延遲同時對系統的需求。 您可以預期具有合理延遲的最佳輸送量。 當輸送量改善時，壓力 (例如，較高的 CPU 耗用量、較高的磁片 I/O 爭用、記憶體壓力，以及系統上) 更大的鎖定爭用。 這種情況可能會對延遲造成負面影響。 若要探索系統的最佳容量，建議您找出並最小化任何瓶頸。

資料庫內已完成的實例可能會導致瓶頸。 發生瓶頸時，效能可能會降低。 讓系統有足夠的時間清空，有助於修正問題。 探索待辦專案建置的原因，並協助修正問題很重要。

若要探索待辦專案的原因，您可以分析歷程記錄資料並監視效能計數器， (探索使用模式，並診斷待辦專案) 的來源。 通常，當大量資料以批次方式處理時，可能會以夜間方式處理待辦專案。 您可能會發現探索系統的容量及其從待辦專案復原的能力很有用。 這項資訊可協助您預估處理超驅案例的硬體需求，以及要容納在系統內的緩衝空間數量，以處理輸送量的未預期尖峰。

監視效能計數器有助於在執行時間產生潛在瓶頸。 不過，當我們懷疑 CPU 或記憶體瓶頸的推斷可能是組成解決方案的其中一個自訂群組件時，強烈建議您在效能測試期間使用 Visual Studio Profiler 或 ANTS 效能分析工具等分析工具，以縮小和縮小產生問題的類別。 顯然，分析應用程式會干擾效能。 因此，這些測試應著重于將造成記憶體耗用量、CPU 使用率或延遲的元件，以及在這些測試期間收集的圖形，應捨棄這些元件。

調整系統以獲得最佳的永續性輸送量，需要深入瞭解已部署的應用程式、系統的優點和缺點，以及特定案例的使用模式。 探索瓶頸並可靠預測最佳、具持續性輸送量的唯一方法，是透過在最符合實際執行的拓撲上進行完整測試。 針對特定使用案例執行負載和壓力測試時，將單一成品隔離 (接收位置、傳送埠、協調流程) 個別主機實例，並在效能監視器工具內設定正確的計數器，對於縮小瓶頸的原因非常重要。

本節中的其他主題會引導您完成定義該拓撲的程式，並提供如何減少並避免瓶頸的指引。

調整大小

已部署拓撲的各個階段可能會發生瓶頸。 某些瓶頸可藉由相應增加或相應放大環境來解決。 相應增加是升級現有電腦的程式。 例如，您可以將BizTalk Server電腦從四個處理器電腦升級至八個處理器電腦，以及替代現有的 CPU 並新增更多 RAM。 如此一來，您就可以加速大量資源的工作，例如檔剖析和對應。 相應放大是將伺服器新增至部署的程式。 相應增加或相應放大的決策取決於瓶頸類型和所設定的應用程式。 應用程式必須從頭開始建置，才能利用相應增加或相應放大。下列指引說明如何根據遇到的瓶頸變更硬體部署拓撲。

相應增加 表示在升級的硬體 (上執行 BizTalk 解決方案，例如，新增 CPU 和記憶體) 。 您應該查看相應增加 1) 相應放大太昂貴，或 2) 相應放大無法協助解決瓶頸。 例如，如果您在更快速的電腦上執行工作，可以大幅減少轉換和處理大型訊息所花費的時間。

相應放大應用程式平臺包含將 BizTalk 節點新增至BizTalk Server群組，並使用這些節點來執行解決方案的一或多個部分。 當您需要隔離傳送、接收、處理、追蹤主機或 2) 記憶體、I/O 或網路 I/O 資源針對單一伺服器時，您應該查看 1 個) 相應放大。 負載可以分散到多部伺服器;不過，將新節點新增至BizTalk Server群組可能會增加 MessageBox 資料庫的鎖定爭用。

那麼，您應該相應增加或相應放大？ 相應增加您的平臺可減少 BizTalk 解決方案的延遲，因為它讓單一工作 (例如訊息對應) 執行速度更快。 相應放大可以改善 BizTalk 解決方案的最大永續性，因為它可讓您將工作負載分散到多部電腦。

另請參閱

尋找並排除瓶頸