何謂持續性效能？

發行項
10/14/2023

在規劃和評估系統的持續性時，考慮長期持續性是很重要的。主要考量為：

載入設定檔和效能目標：在載入設定檔和效能目標方面，您無法有太多詳細資料。測試與整備憑證將會以能夠長期處理這些負載為基礎。
其他競爭伺服器資源的活動和程式：不只是訊息載入。伺服器上還有其他程序與活動，會影響像是資料庫維護與 MessageBox 查詢的效能。
計劃性與非計劃性系統中斷和停機時間：Floodgate 事件和訊息待處理專案可以變更有效的負載設定檔。

在考慮建置持續性系統及測試以認證這些系統時，請確定將這些因素納入考量並加以規劃。

您的效能可持續嗎？

討論BizTalk Server的效能時，我們會定義最大永續性效能，如下所示：

在生產環境中，系統可無限處理的最高負載訊息流量。

雖然這看起來很簡單，但是當您將解決方案放置於生產環境之後，在評估於特定硬體上執行的解決方案是否可支援每日出入的負載時，必須考慮許多因素。

將解決方案放置於生產環境之前，請先考慮下列因素，以評估此解決方案是否可無限處理最高負載訊息流量：
預期的效能目標與輸送量/延遲設定檔。
在相同硬體上執行的其他程序，例如：
- 正常監控與疑難排解
- 作業資料庫維護，例如，記錄傳送、備份、清除、索引維護，以及統計資料更新。
- 其他應用程式
計劃與非計劃的系統中斷，例如：
- 夥伴網站停機而封鎖傳送或接收訊息
- 定期系統維護停機時間

瞭解您的效能目標

在評估解決方案的持續性之前，您必須詳細瞭解預期的生產負載。若未詳細瞭解目標，就無法評估整備。良好的效能目標是很重要的，因為它會引導您的系統測試與憑證策略。您的效能目標應有下列項目：

以時間函式來定義效能的曲線。這些函式涵蓋的範圍可從極簡單到非常複雜。
與效能函式關聯的效能需求。
檔案大小與類型的散佈。

範例 1

每天的訊息會從上午 8 點的 0 msgs/sec 開始累積，到中午的 80 msgs/sec，然後在下午 9 點回到 0 msgs/sec，大約會是個鐘形曲線。
系統對每個訊息沒有特定的延遲需求，但它必須可以處理此負載，加上前一天載入的所有訊息 (例如，系統中斷 24 小時的狀況)，而不會有所落後。
有三種文件類型：「購物籃」、「補貨」及「庫存要求」。「購物籃」文件的大小介於 2 到 10 KB 之間，並於任何指定時間中組成 75% 的訊息計數。「補貨」與「庫存要求」文件的大小一律會接近 1 KB，並於任何指定時間中分別組成其餘 10% 與 15% 的訊息計數。

範例 2

在每天午夜，需要處理一個 500,000 個訊息的批次。
必須在 8 小時內處理完批次中的所有訊息。
所有訊息都是相同類型，平均分散於 10 KB 到 50 KB (含) 之間。此外，該批次一定包含 10 個目錄類型訊息，每個均為 10 MB，而且必須再分成個別的目錄項目才能處理。

範例 3

4000 位客戶服務代表在每天上午 8 點登入互動系統，平均每位代表每分鐘會執行 4 個查詢，直到下午 5 點關機為止，每週七天都是如此。
所有的查詢都必須在 2 秒內傳回結果。
所有查詢都是相同類型，其大小平均分散於 500 到 1000 個位元組 (含) 之間。

與效能函式關聯的效能需求

繼續上述範例：

範例 1 (繼續) ：系統對於每個訊息沒有特定的延遲需求，但必須能夠處理此 (負載，例如，在 24 小時系統中斷時，系統必須能夠處理此負載，例如，在 24 小時系統中斷時) 。
範例 2 (繼續) ：批次中的所有訊息都必須在 8 小時內處理完成。
範例 3 (繼續) ：所有查詢都必須傳回少於 2 秒的結果。

檔案大小與類型的散佈

範例 1 (繼續) ：有三種檔案類型：銷售籃、退單和庫存要求。「購物籃」文件的大小介於 2 到 10 KB 之間，並於任何指定時間中組成 75% 的訊息計數。「補貨」與「庫存要求」文件的大小一律會接近 1 KB，並於任何指定時間中分別組成其餘 10% 與 15% 的訊息計數。
範例 2 (繼續) ：所有訊息的類型都相同，且平均分散在 10 到 50 KB 之間，包含。此外，該批次一定包含 10 個目錄類型訊息，每個均為 10 MB，而且必須再分成個別的目錄項目才能處理。
範例 3 (繼續) ：所有查詢的類型都相同，且大小平均分散在 500 到 1000 個位元組之間，包含。

說明其他程序

除了直接透過 BizTalk 引擎傳送的負載設定檔之外，總是會有其他程序競爭相同硬體上的資源。這些程序將降低系統之整體持續性效能的能力。資料庫維護可能是這類程序的最常見範例。

每個資料庫 (大型或小型) 都需要定期作業維護，例如，記錄傳送、備份、封存，以及清除。監控與疑難排解是您在定義和認證何謂持續性時必須考慮的其他作業範例。例如，查詢 MessageBox (例如，透過管理主控台 [群組中樞] 頁面) 來查看過去 24 小時有多少指定類型的訊息遭到擱置，需要 SQL Server 已用來處理訊息的資源。

以下是一份活動清單，通常會對BizTalk Server的整體永續性產生最大影響：

記錄傳送和備份。在涉及SQL Server的大部分災害復原計畫中，您必須針對所有BizTalk Server群組資料庫定期執行記錄傳送和備份。如需詳細資訊，請參閱備份和還原BizTalk Server資料庫。另請參閱記錄傳送。
封存和清除追蹤資料。除了整體記錄傳送和備份計畫之外，BizTalk 追蹤 (BizTalkDTADb) 資料庫也有自己的封存和清除記錄;如需詳細資訊，請參閱封存和清除 BizTalk 追蹤資料庫。從 BizTalk 追蹤資料庫封存和清除資料的速度尤其重要，因為封存和清除 BizTalk 追蹤資料庫通常是使用追蹤時的瓶頸。
系統查詢。使用 API 或 BizTalk Server 管理主控台 UI 對系統執行各種類型的查詢，將會影響持續性效能。
MessageBox 維護。有數個 SQL 作業屬於BizTalk Server的核心功能，可藉由清除已完成處理的訊息和實例來維護 MessageBox 資料庫。做為核心引擎的一部分，完成這些工作的速度是衡量持續性的關鍵因素。如需這些作業及其角色的詳細資訊，請參閱維護 BizTalk Server1。
解決方案部署活動。在部署、繫結和啟動新應用程式或現有應用程式的新版本時，額外的負載是放置於 BizTalk 上，像是在 MessageBox 資料庫上建立新訂閱。部署應用程式之後，已處理的訊息將競爭資源，因而影響現有應用程式的效能。

對於其中的每個區域，您必須詢問：若要將這些活動的衝擊最小化，您有何建議？例如，他們應該計劃在凌晨 3 點執行它們嗎？

考慮計劃與非計劃的中斷

中斷對於系統效能的影響，會根據經歷中斷的系統不同而變動，不過，最常見的結果如下：

Floodgate 事件。當系統停機一段長時間時，訊息會累積，然後在系統再次恢復運作時全部同時抵達以進行處理。例如，若在 BizTalk 上執行的應用程式會透過 MSMQ 接收訊息，且該應用程式停機一段時間，則訊息會累積在佇列中，以等待收取。當應用程式再度啟動時，就像有大量訊息「全部同時」抵達。
訊息待辦專案。當訊息要傳送至的系統停機時，通常會有使用其他資源的重試週期。重試週期耗盡之後，訊息通常會暫停。然後，當停機的系統恢復線上運作時，就會發生大量事件的類型，現在可以繼續和 (或) 成功地傳送大量訊息。

當然，像是定期排程維護的任何計劃中斷，在設計和認證系統時都必須列入考慮。同時建議您考慮分析非計劃的中斷及其影響。

識別可能發生的中斷類型，藉由評估風險層級 (也就是可能性乘以嚴重性) 和較高風險中斷的持續時間與影響 (例如，大量事件、已擱置的訊息數量、積存等) 將它們排列等級，將指示系統可能發生中斷的可能性。任何儲存和轉寄、傳訊型非同步系統，例如BizTalk Server，都應該設計為處理足以應付計劃性和非計劃性中斷的「前端」。

另請參閱

引擎持續性和耐久性
 依階段的專案規劃建議
 測量最大的可負載引擎輸送量
 測量最大持續性追蹤輸送量
 擴充您的解決方案
 識別效能瓶頸
 引擎效能和容量

共用方式為