耐用功能中的效能與規模

利用本文調整你的 Durable Functions 應用程式的效能與擴展行為。 它涵蓋了你可以調整的主要槓桿：

• 工作者擴展：Azure Functions 主機如何根據負載新增或移除工作者。
• 並行限速：如何限制每個工作者同時執行的函式數量。
• 執行個體快取：如何透過在工作者記憶體中快取協調流程狀態，減少重新執行負荷。
• 分割區數量：如何配置分割以擴展與區域化。

背景工作者調整

任務中心概念的一大優勢是處理任務中心工作項目的工人數量會不斷增加或減少。 應用程式會新增工作者 (擴展) 以加快處理工作，當工作不足以讓工作者忙碌時，則移除工作者 (縮減)。 你甚至可以在任務中心閒置時調整 到零 。 當您縮放為零時，將不會有任何背景工作者執行。 只有秤控制器和儲存裝置仍然啟用。

下圖說明此概念：

自動縮放

在 Consumption 和 Elastic Premium 計畫中，Durable Functions 支援透過 Azure Functions 調整比例控制器 進行自動擴展。 擴展控制器會監視訊息與工作在處理前等待的時間長度。 根據這些延遲，它會新增或移除工人。

在高級方案中，自動擴展會讓工作者數量（及營運成本）大致與應用程式負載成正比。

並行節流

單一工作者實例可以同時執行多個 工作項目 。 這提升了平行性並更有效率地利用了工作者資源。 但如果工作者同時處理過多工作項目，可能會耗盡 CPU、網路連線和記憶體等資源。

為避免單一背景工作者承擔過多工作，您可能需要限制每個執行個體的並行數。 限制每個工作者同時執行的功能數量，有助於避免觸及該工作者的資源限制。

設定並行節流

在 host.json 檔案中設定活動、協調器與實體函式的並行限制。 將 durableTask/maxConcurrentActivityFunctions 用於活動函數，將 durableTask/maxConcurrentOrchestratorFunctions 用於編排器與實體函數。 這些設定限制了工作者在記憶體中載入的編排器、實體及活動函式數量。

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

語言執行階段考量

你選擇的語言執行時可以對函式施加嚴格的並行限制。 例如，使用 Python 或 PowerShell 撰寫的 Durable Functions 應用程式，一次只能在單一虛擬機上執行一個函式。 如果沒考慮到這點，可能會造成效能問題。 如果協調器扇出至 10 個活動，但語言執行階段只允許執行一個函式，則 10 個活動函式中有 9 個會卡住，等待執行機會。 此外，這些等待中的活動也無法負載平衡到其他背景工作者，因為 Durable Functions 執行階段已將它們載入記憶體。 當活動功能長時間運行時，這尤其令人擔憂。

如果你的語言執行時限制並行，請更新 Durable Functions 的並行設定以符合它。 這樣可以避免 Durable Functions 執行時同時執行超過語言執行環境允許的函式，並讓待處理的作業能夠分攤至其他虛擬機上。 例如，如果一個Python應用程式限制並行性為四個函式（例如，單一語言工作程序有 4 個執行緒，或 4 個語言工作程序有 1 執行緒），則將 maxConcurrentOrchestratorFunctions 和 maxConcurrentActivityFunctions 都設為 4。

關於Python效能建議，請參見 提升 Azure Functions。 這些技術能顯著提升 Durable Functions 的效能與可擴展性。

執行個體快取

處理 編排工作項目時，工作者會做兩件事：

1. 提取協調流程歷程記錄。
2. 利用歷史資料重播編排器程式碼。

若同一工作者處理多個工作項目以執行同一編排，儲存提供者可在工作者記憶體中快取歷史，以省去第一步。 它也可以快取執行中期的協調器，避免後續工作項目重播歷程記錄。

當您的協調流程有許多段落，且重新執行負荷偏高時，請啟用快取。 快取通常會減少對基礎儲存體服務的 I/O，並改善輸送量和延遲，但也會增加工作者記憶體使用量。

依儲存體提供者的快取

下表比較各服務提供者的實例快取支援，並總結如何配置每一個。

延伸工作階段 (Azure 儲存設備提供者)

延伸工作階段會將執行中的協調者保留在記憶體中，直到其閒置達一定時間為止。 請在你的 extendedSessionsEnabled 檔案中extendedSessionIdleTimeoutInSeconds啟用並調整此行為：

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

實例快取（Netherite 儲存提供者）

實例快取會將實例狀態和歷史記錄保存在工作者的記憶體中，並追蹤總記憶體使用量。 如果快取超過 InstanceCacheSizeMB 限制，會逐出最近使用最少的實例資料。 如果您將 CacheOrchestrationCursors 設定為 true，快取也會儲存執行中期的協調器。

分割區數量

有些儲存服務商支援 分割 ，並允許你設定 partitionCount。

透過分割，員工不會為了個別工作項目而競爭。 分割時會將工作項目分成 partitionCount 分割區，執行時則將分割區指派給工作者。 此方法可減少總儲存存取次數。 它也支援 實例快取 ，並透過建立 親和性來提升局部性：同一工作者為同一實例處理所有工作項目。

對大多數應用程式來說，預設的分割區數量就足夠了。 如果您預期協調流程會超出預設工作者數量進行調整，請增加此值，因為分割區計數會限制可從已分割佇列處理協調流程訊息的工作者數量。

下表顯示每個儲存體提供者會分割哪些佇列，以及 partitionCount 的允許範圍與預設值。

設定分割區數量

請在 partitionCount 檔案中指定。 以下 host.json 片段設定 durableTask/storageProvider/partitionCount 為 3。

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

函式執行行為

本節涵蓋影響效能的執行細節：每種函式類型應處理什麼樣的工作、逾時機制如何運作，以及實體操作如何批次處理。

按功能類型的工作配置

編排器功能的邏輯會被多次執行，因為它們會重複運行。 因此，編排器功能執行緒不執行 CPU 密集型任務、不執行 I/O 或阻塞非常重要。 將可能需要 I/O、封鎖或多執行緒的工作移至活動函式中。

活動函式 的行為類似一般的隊列觸發函式。 它們支援 I/O、CPU 密集型操作以及多執行緒。 因為活動觸發器是無狀態的，它們會擴展到多個虛擬機。

實體函式 也在單一執行緒上執行，並逐一處理操作。 實體函式對執行的程式碼類型沒有限制。

函式逾時

活動、編排器與實體函式遵循與其他 Azure Functions 相同的函數逾時規則。 Durable Functions 將函式逾時視為程式碼中的未處理例外。

例如，當某項活動逾時時，Durable Functions 會記錄執行失敗並通知編排器。 編排器會像處理其他例外一樣處理逾時：如果呼叫指定了重試次數，執行環境就會重試，或者執行例外處理程序。

實體作業批次處理

為了提升效能並降低成本，單一工作項目可以執行一批實體操作。 在 Consumption 方案中，每個批次都會以單一函式執行計費。

預設情況下，消費方案的最大批次容量為 50 人，其他方案則為 5,000 人。 你也可以在 host.json 檔案中設定最大批次大小。 如果批次大小的最大值是 1，則實際上批次處理已被停用。

效能目標

當你規劃使用 Durable Functions 的生產應用程式時，應及早考慮效能需求。 以下基本使用情境有助於規劃：

• 序列活動執行：此情境描述一個編排器函式，依序執行一系列活動函數。 它最相似函數鏈式範例。
• 平行活動執行：此情境描述一個編排器函式，透過 Fan-out， fan-in 模式並行執行多個活動函式。
• 平行回應處理：此情境是 「扇出扇入 」模式的後半段。 它著重於扇入效能。 與 fan-out 不同，fan-in 運行於單一的 orchestrator 函式實例中，因此它運行於單一虛擬機上。
• 外部事件處理：此情境描述一個編排器函式實例，其依次等待每一個外部事件。
• 實體操作處理：此情境測試 單一計數器實體 處理持續操作流的速度。

這些情境的吞吐量數據載於儲存供應商文件中。 特別是：

• 關於持久任務排程器，請參見行動吞吐量基準測試。
• 關於Azure 儲存體提供者，請參見績效目標。
• 關於奈瑟萊特儲存供應商，請參見 基本情境。
• 關於 MSSQL 儲存提供者，請參見 協作處理效能基準。

下一步