在內部基準測試中，Durable Task Scheduler 處理工作項目的速度約為 Azure 儲存體 提供者的 五倍，後者是 Durable Functions 應用程式最常用的後端。
動作是排程器處理的任何離散操作，例如啟動編排、排程活動或處理計時器。 完整定義與帳單細節，請參閱「 什麼是行動？」
基準測試結果
長期工作排程器已針對其他記憶體提供者進行效能評定，包括 Azure 記憶體、MSSQL 和 Netherite 提供者。 結果顯示，持久任務排程器提供比其他選項更好的 動作 吞吐量，這意味著在特定時間內處理更多協調器、實體與活動任務。
以下圖表顯示了不同工作者數量下，Durable Task Scheduler 與 Azure 儲存體 供應商每秒處理的工作項目數。 選擇 Azure 儲存體 供應商作為比較，因為它是 Durable Functions 應用程式的預設且最常用的後端。
下表總結了基準測試的數值吞吐量：
| 組態 | Azure 儲存體（工作項目/秒） | 持久任務排程器（工作項目/秒數） | 加速 |
|---|---|---|---|
| EP2,1名工人 | ~250 | ~1,400 | ~5.6x |
| EP2，兩名工人 | ~430 | ~2,750 | ~6.4x |
| EP2,4名工人 | ~830 | ~3,750 | ~4.5x |
備註
這些結果來自內部基準測試，旨在粗略比較相對表現。 你的結果會依工作量特性而有所不同。
基準方法論
為了測試後端提供者的相對輸送量，這些效能評定是使用標準協調器函式來執行，該函式會依序呼叫五個活動函式，每個城市各呼叫一個活動函式。 每個活動只會傳回 “Hello， {cityName}！” 字串值，而且不會執行任何其他工作。
基準檢驗的意圖是測量每個後端的額外負荷，而不需要執行任何過於複雜的動作。 之所以選擇這種類型的循序協調流程，是因為其在包含 Durable Functions 的函式應用程式中很常見。
測試詳情
測試包含下列準則：
- 用於此測試的函式應用程式會在 一到四個彈性進階EP2實例上執行。
- 編排程式碼以 C# 撰寫，使用 .NET 孤立工作者模型，運行於 .NET 8。
- 所有記憶體提供者都使用相同的應用程式，唯一的變更是後端記憶體提供者設定。
- 測試會透過一個 HTTP 觸發程式，同時啟動 5,000 個協調流程來執行。
測試完成之後，輸送量的計算方式是將已完成的協調流程總數除以總運行時間。 測試會針對每個記憶體提供者組態執行多次，以確保結果一致。
影響你結果的因素
您的結果可能會因下列情況而有所不同：
- 您協調流程和活動的複雜性
- 同時執行的協調流程數量
- 協調流程與活動之間傳遞的資料承載大小
- 虛擬機器大小與 SKU
- 你的運算與排程器之間的網路延遲
備註
這些基準測試由 Microsoft 內部執行，並未提供獨立的測試工具。 它們的目的是讓你在選擇儲存後端時，大致了解相對效能。