Windows Workflow Foundation 4 效能

.NET Framework 4 包含 Windows Workflow Foundation （WF） 的重大修訂，對效能進行大量投資。 這個新修訂引進了舊版 WF 的重大設計變更，這些 WF 隨附於 .NET Framework 3.0 和 .NET Framework 3.5。 它已從程序設計模型、運行時間和工具的核心重新建構，以大幅改善效能和可用性。 本主題顯示這些修訂的重要效能特性，並將其與舊版的效能進行比較。

個別工作流程元件的效能在 WF3 到 WF4 之間呈現數量級的增長。 這會使手動編碼的 Windows Communication Foundation （WCF） 服務和 WCF 工作流程服務之間的差距相當小。 WF4 中的工作流程延遲已大幅降低。 持久效能已提升至 2.5 到 3 倍。 透過工作流程追蹤進行健康情況監視，額外負荷明顯較少。 這些是移轉至或採用應用程式中 WF4 的令人信服的理由。

術語

.NET Framework 4 中引進的 WF 版本將在本主題的其餘部分稱為 WF4。 WF 已在 .NET Framework 3.0 中引進，並透過 .NET Framework 3.5 SP1 進行一些次要修訂。 本主題其餘部分的 .NET Framework 3.5 版 Workflow Foundation 將以下簡稱為 WF3。 WF3 與 WF4 並列在 .NET Framework 4 中一同發布。 如需將 WF3 成品移轉至 WF4 的詳細資訊，請參閱： Windows Workflow Foundation 4 移轉指南。

Windows Communication Foundation （WCF） 是建置服務導向應用程式的統一程序設計模型Microsoft。 它最初是 .NET Framework 3.0 與 WF3 一起引進的，現在是 .NET Framework 的主要元件之一。

Windows Server AppFabric 是一組整合式技術，可讓您更輕鬆地建置、調整及管理在 IIS 上執行的 Web 和複合應用程式。 它提供監視及管理服務和工作流程的工具。 如需詳細資訊，請參閱 Windows Server AppFabric 1.0。

目標

本主題的目標是要顯示WF4的效能特性，以及針對不同案例測量的數據。 它也會提供 WF4 與 WF3 之間的詳細比較，因此顯示這項新修訂中所做的重大改進。 本文所呈現的案例和數據會量化 WF4 和 WF3 不同層面的基礎成本。 此數據有助於瞭解 WF4 的效能特性，並有助於規劃從 WF3 移轉至 WF4 或在應用程式開發中使用 WF4。 不過，對於從本文所呈現的數據中得出的結論，應該謹慎對待。 複合工作流程應用程式的效能高度相依於工作流程的實作方式，以及不同元件的整合方式。 一個必須測量每個應用程式，以判斷該應用程式的效能特性。

WF4 效能增強功能概觀

WF4 經過精心設計和實作，具有高效能和延展性，如下列各節所述。

WF 運行時間

WF 執行環境的核心是一個異步排程器，驅動工作流程中各項活動的執行。 它為活動提供高效能且可預測的執行環境。 環境具有妥善定義的執行、接續、完成、取消、例外狀況和可預測的線程模型合約。

相較於 WF3，WF4 運行時間具有更有效率的排程器。 它會利用用於 WCF 的相同 I/O 線程集區，這對執行批次工作專案非常有效率。 內部工作專案排程器佇列已針對最常見的使用模式進行優化。 WF4 執行階段也會以非常輕量的方式管理執行狀態，使用最少的同步和事件處理邏輯，而 WF3 則依賴於繁重的事件註冊和調用，以執行複雜的同步以進行狀態轉換。

數據儲存和流動

在 WF3 中，與活動相關聯的數據是透過類型 DependencyProperty所實作的相依性屬性來建立模型。 相依性屬性模式是在 Windows Presentation Foundation （WPF） 中引進的。 一般而言，此模式非常有彈性，可支援簡單的數據系結和其他UI功能。 不過，模式需要將屬性定義為工作流程定義中的靜態欄位。 每當 WF 運行時間設定或取得屬性值時，就會牽涉到大量加權的查閱邏輯。

WF4 使用清楚的數據範圍邏輯，大幅改善工作流程中數據的處理方式。 它會使用兩個不同的概念，將儲存在活動中的數據與流經活動界限的數據分開：變數和自變數。 藉由針對變數和 "In/Out/InOut" 參數使用清楚的組織化範圍，活動中的數據使用複雜度會大幅降低，而且數據的存留時間也會自動設定範圍。 活動具有其參數所描述的明確定義特徵。 只要檢查操作，您就可以判斷其預期接收哪些數據，以及執行後會產生哪些數據。

在建立工作流程時，WF3 活動已被初始化。 只有在對應的活動執行時，WF 4 活動才會初始化。 這允許在建立新的工作流程實例時執行較簡單的活動生命週期，而不需要執行初始化/取消初始化作業，因此已達到更高的效率

控制流

如同任何程式設計語言，WF 藉由引進一組用於排序、迴圈、分支和其他模式的控制流程活動，來支援工作流程定義的控制流程。 在 WF3 中，當需要重新執行相同的活動時，會建立新的 ActivityExecutionContext，而且活動會透過以 BinaryFormatter 為基礎的重量級串行化和還原串行化邏輯來複製。 反覆控制流程的效能通常比執行一連串的活動慢得多。

WF4 會以完全不同的方式處理這個。 它會採用活動範本、建立新的 ActivityInstance 物件，並將它新增至排程器佇列。 此整個程式只牽涉到明確的物件建立，而且非常輕量。

異步程序設計

應用程式通常具有較佳的效能和延展性，可透過異步程式設計進行長時間執行的封鎖作業，例如 I/O 或分散式運算作業。 WF4 透過基底活動類型 AsyncCodeActivity、 AsyncCodeActivity<TResult>提供異步支援。 執行階段天然理解異步活動，因此在異步工作未完成時，可以自動將實例置於不保留狀態的區域中。 自定義活動可以衍生自這些類型來執行異步工作，而不需要保存工作流程排程器線程，並封鎖任何可能可以平行執行的活動。

訊息傳送

最初 WF3 透過外部事件或 Web 服務調用提供非常有限的傳訊支援。 在 .NET Framework 3.5 中，工作流程可以實作為 WCF 用戶端，或透過 SendActivity 和 ReceiveActivity公開為 WCF 服務。 在 WF4 中，工作流程型傳訊程式設計的概念透過將 WCF 傳訊邏輯緊密整合至 WF，進一步強化。

.NET 4 中 WCF 中提供的整合訊息處理管線可協助 WF4 服務具有比 WF3 更好的效能和延展性。 WF4 也提供更豐富的傳訊程式設計支援，可模型化複雜的訊息交換模式（MEP）。 開發人員可以使用具類型的服務合約來達成簡單的程序設計或未具類型的服務合約，以達到更佳的效能，而不需要支付串行化成本。 透過 WF4 類別的 SendMessageChannelCache 用戶端通道快取支援，可協助開發人員以最少的努力建置快速應用程式。 如需詳細資訊，請參閱 變更傳送活動的快取共用層級。

宣告式程序設計

WF4 提供全新且簡單的宣告式程式設計架構，以建立商務程式和服務的模型。 程序設計模型支援完全宣告式的活動組合，不需要程式代碼，可大幅簡化工作流程撰寫。 在 .NET Framework 4 中，XAML 型宣告式程式設計架構已整合至單一元件 System.Xaml.dll，以支援 WPF 和 WF。

在 WF4 中，XAML 提供真正的宣告式體驗，並允許在 XML 標記中定義整個工作流程定義，並參考使用 .NET 建置的活動和類型。 這在 WF3 中使用 XOML 格式而不涉及自訂程式碼後端邏輯是很困難的。 .NET 4 中的新 XAML 堆棧在串行化/還原串行化工作流程成品方面具有更好的效能，並讓宣告式程序設計更具吸引力且穩固。

工作流程設計工具

WF4 的完整宣告式程式設計支持明確對大型工作流程的設計時間效能提出了更高的需求。 WF4 中的工作流程設計工具對於大型工作流程具有比 WF3 更好的延展性。 透過UI虛擬化支援，設計工具可以在幾秒鐘內輕鬆載入1000個活動的大型工作流程，而幾乎不可能使用WF3設計工具載入數百個活動的工作流程。

元件層級效能比較

本節包含 WF3 和 WF4 工作流程中個別活動之間的直接比較數據。 持續性等關鍵領域比個別活動元件對效能產生更深的影響。 不過，WF4 中個別元件的效能改善很重要，因為元件現在夠快，可以與手動編碼的協調流程邏輯進行比較。 下一節涵蓋的範例是：「服務組合案例」。

環境設定

上圖顯示用於元件層級效能測量的計算機組態。 透過一個 1 Gbps 乙太網路介面連線的單一伺服器和五個用戶端。 為了方便測量，伺服器會設定為使用執行 Windows Server 2008 x86 之雙程式/四核心伺服器的單一核心。 系統 CPU 使用率維持在近 100%。

測試詳細數據

WF3 CodeActivity 可能是可用於 WF3 工作流程的最簡單活動。 活動會呼叫程式代碼後置中的方法，該方法允許工作流程程式設計人員加入自定義的程式代碼。 在 WF4 中，沒有直接對應於 WF3 CodeActivity 提供相同功能的元素。 請注意，WF4 中有一個 CodeActivity 與 WF3 CodeActivity無關的基類。 鼓勵工作流程作者建立自定義活動，並建置僅限 XAML 的工作流程。 在下列測試中，會使用名為 Comment 的活動來取代 WF4 工作流程中的空白 CodeActivity 。 活動中的程式代碼 Comment 如下所示：

[ContentProperty("Body")]
    public sealed class Comment : CodeActivity
    {
        public Comment()
            : base()
        {
        }

        [DefaultValue(null)]
        public Activity Body
        {
            get;
            set;
        }

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

空白工作流程

此測試會使用沒有子活動的序列工作流程。

單一活動

工作流程是包含一個子活動的時序工作流程。 活動在 WF3 案例中是沒有程式碼的 CodeActivity，而在 WF4 案例中是 Comment 活動。

當有1000次迭代時

時序工作流程包含一個活動，其中一個 While 子活動在迴圈中不會執行任何工作。

與 ParallelForEach 比較的複寫器

ReplicatorActivity 在 WF3 中具有循序和平行執行模式。 在循序模式中，活動的效能類似於 WhileActivity。 ReplicatorActivity最適合平行執行。 對此的 WF4 模擬是 ParallelForEach<T> 活動。

下圖顯示用於此測試的工作流程。 WF3 工作流程位於左側，而 WF4 工作流程位於右側。

具有五個活動的循序工作流程

此測試旨在顯示讓數個活動依序執行的效果。 順序中有五個活動。

交易範圍

交易範圍測試與其他測試稍有不同，因為不會針對每個反覆專案建立新的工作流程實例。 取而代之的是，工作流程使用 while 循環結構化，其中包含一個含有單一活動的TransactionScope活動，該活動未執行任何工作。 每執行一次 50 次迭代的一批時，while 迴圈都會被計算為單一操作。

薪酬

WF3 工作流程具有名為 WorkScope的單一補償活動。 活動只會實作 ICompensatableActivity 介面：

class WorkScope :
        CompositeActivity, ICompensatableActivity
    {
        public WorkScope() : base() { }

        public WorkScope(string name)
        {
            this.Name = name;
        }

        public ActivityExecutionStatus Compensate(
            ActivityExecutionContext executionContext)
        {
            return ActivityExecutionStatus.Closed;
        }
    }

錯誤處理程序將目標設為WorkScope活動。 WF4 工作流程同樣簡單。 CompensableActivity具有主體和補償處理程式。 明確的補償是序列中接下來的項目。 這兩項活動：主體活動和補償處理程序活動，都是空白的實作。

public sealed class CompensableActivityEmptyCompensation : CodeActivity
    {
        public CompensableActivityEmptyCompensation()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }
    public sealed class CompensableActivityEmptyBody : CodeActivity
    {
        public CompensableActivityEmptyBody()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }

下圖顯示基本補償工作流程。 WF3 工作流程位於左側，而 WF4 工作流程位於右側。

效能測試結果

所有測試都會以每秒的工作流程來測量，但交易範圍測試除外。 如上所示，WF 運行效能已全方位改善，特別是在需要多次執行相同活動的區域，例如 while 迴圈。

服務組合案例

如上一節所示，「元件層級效能比較」已大幅降低WF3與WF4之間的額外負荷。 WCF 工作流程服務現在幾乎可以符合手動編碼 WCF 服務的效能，但仍具有 WF 運行時間的所有優點。 此測試案例會比較 WCF 服務與 WF4 中的 WCF 工作流程服務。

在線商店服務

Windows Workflow Foundation 的優點之一是能夠使用數個服務撰寫程式。 在此範例中，有一個網路商店服務會安排兩個服務呼叫來完成訂單購買。 第一個步驟是使用訂單驗證服務來驗證訂單。 第二個步驟是使用倉儲服務填滿訂單。

這兩個後端服務「訂單驗證服務」和「倉儲服務」在兩個測試中維持不變。 變更的部分是執行協調流程的在線商店服務。 在某種情況下，服務被手動編寫為 WCF 服務。 若為另一種情況，服務會在WF4中寫入為WCF工作流程服務。 此測試會關閉追蹤和持續性等 WF 特定功能。

環境

客戶端請求透過多部計算機以 HTTP 發送至線上商店服務。 單一電腦主機三項服務。 在線商店服務與後端服務之間的傳輸層為 TCP 或 HTTP。 每秒操作次數的測量是根據對線上商店服務進行的已完成 PurchaseOrder 呼叫數目。 通道共用是 WF4 中提供的新功能。 在此測試中，WCF 的通道共用並未出廠提供，因此在在線商店服務中，使用了手動編碼的簡單資源共用技術來實作。

績效

在沒有頻道共用的情況下連線到後端 TCP 服務時，WF 服務會對輸送量造成 17.2% 的影響力。 使用通道共用時，懲罰約為 23.8%。 對於 HTTP 而言，影響要少得多：不使用共用是 4.3%，使用共用是 8.1%。 也請務必注意，通道共用在使用 HTTP 時提供非常小的好處。

雖然相較於此測試中的手動編碼 WCF 服務，WF4 運行時間會有額外負荷，但可能會被視為最壞的情況。 此測試中的兩個後端服務執行的工作很少。 在實際的端對端案例中，這些服務會執行更昂貴的作業，例如資料庫呼叫，使得傳輸層的效能影響較不重要。 再加上 WF4 中可用功能的優點，讓 Workflow Foundation 成為建立協調流程服務的可行選擇。

關鍵效能考慮

本節中的功能區域，除 Interop 之外，WF3 與 WF4 之間已經發生了顯著變化。 這會影響工作流程應用程式的設計以及效能。

工作流程啟用延遲

在 WCF 工作流程服務應用程式中，啟動新工作流程或載入現有工作流程的延遲很重要，因為它可能會封鎖。 此測試案例會在典型場景下比較並測量 WF3 XOML 主機與 WF4 XAMLX 主機的效能。

環境設定

測試設定

在此案例中，用戶端電腦會使用內容關聯來連絡 WCF 工作流程服務。 內容相互關聯需要特殊的內容系結，並使用內容標頭或 Cookie 將訊息與正確的工作流程實例產生關聯。 其效能優點在於相互關聯標識符位於訊息標頭中，因此不需要剖析訊息本文。

服務會使用要求建立新的工作流程，並傳送立即回應，讓延遲的測量不包含執行工作流程所花費的時間。 WF3 工作流程是具有程式碼後置的 XOML，而 WF4 工作流程則完全是 XAML。 WF4 工作流程看起來像這樣：

活動 Receive 會建立工作流程實例。 接收到的訊息中的值會在回覆訊息中被回聲。 回復之後的序列包含工作流程的其餘部分。 在上述案例中，只會顯示一個批注活動。 批注活動的數目會變更為模擬工作流程複雜度。 批注活動相當於不執行任何工作的 WF3 CodeActivity 。 如需批註活動的詳細資訊，請參閱本文稍早的「元件層級效能比較」一節。

測試結果

WCF 工作流程服務的冷和暖延遲：

在前一個圖表中，「冷」指的是在特定的工作流程中不存在 WorkflowServiceHost 的情況。 換句話說，「冷延遲」是指工作流程第一次使用且需要編譯 XOML 或 XAML 的時候。 暖延遲是在工作流程類型已編譯時建立新的工作流程實例的時間。 工作流程的複雜性在 WF4 案例中幾乎沒有差異，但在 WF3 案例中具有線性進展。

相關性吞吐量

WF4 引進了以內容為基礎的新相互關聯功能。 WF3 僅提供以內容為基礎的相互關聯。 內容型相互關聯只能透過特定的 WCF 通道系結來完成。 使用這些系結時，工作流程標識符會插入訊息標頭中。 WF3 運行時間只能依其標識碼來識別工作流程。使用以內容為基礎的相互關聯，工作流程作者可以從帳戶號碼或客戶標識碼等相關數據片段中建立相互關聯索引鍵。

以內容為基礎的相互關聯具有效能優勢，在於相互關聯索引鍵位於訊息標頭中。 已加密的鑰匙可以從訊息中讀取，不必串列化或複製訊息。 在內容型相互關聯中，相互關聯索引鍵會儲存在訊息本文中。 XPath 運算式可用來尋找索引鍵。 此額外處理的成本取決於訊息的大小、訊息主體中金鑰的深度，以及金鑰的數量。 此測試會比較以背景和內容為基礎的相互關聯，並顯示在使用多個鍵時效能降低。

環境設定

測試設定

上一個工作流程與 Persistence 區段中所使用的工作流程相同。 對於沒有持續性的相互關聯測試，運行時間中不會安裝持續性提供者。 相互關聯發生在兩個位置：CreateOrder 和 CompleteOrder。

測試結果

這個圖表顯示，當內容為基礎的相互關聯中使用的索引鍵數目增加時，效能會降低。 TCP 與 HTTP 之間的曲線相似度表示與這些通訊協定相關聯的額外負荷。

與持續性的相互關聯

使用持續性工作流程時，內容型相互關聯產生的CPU壓力會從工作流程運行時間轉移到SQL資料庫。 SQL 持續性提供者中的預存程式會執行比對索引鍵的工作，以找出適當的工作流程。

以內容為基礎的相互關聯仍然比內容型相互關聯更快。 不過，差異較不明顯，因為持續性對效能的影響比相互關聯更大。

複雜工作流程輸送量

工作流程的複雜度不只以活動數目來測量。 複合活動可以包含許多子系，而這些子系也可以是複合活動。 隨著巢狀層級的數目增加，目前處於執行狀態的活動數目和可能處於狀態的變數數目也會增加。 此測試會比較執行複雜工作流程時 WF3 與 WF4 之間的輸送量。

測試設定

這些測試是在搭載 Intel Xeon X5355 @ 2.66GHz、配備 4GB RAM、運行 Windows Server 2008 x64 的 4 路計算機上執行。 測試程式代碼會在每個核心有一個線程的單一進程中執行，以達到 100% CPU 使用率。

針對此測試產生的工作流程有兩個主要變數：每個序列中的活動深度和數目。 每個深度層級都包含平行活動、迴圈、決策、指派和序列。 在下圖的 WF4 設計工具中，會繪製最上層流程圖。 每個流程圖活動類似於主要流程圖。 在想像此工作流程時，可以考慮分形，這樣做可能會有幫助，其中深度受限於測試的參數。

指定測試中的活動數目取決於每個序列的活動深度和數目。 下列方程式會計算 WF4 測試中的活動數目：

WF3 測試的活動計數可以使用稍微不同的方程式來計算，因為有額外的序列：

其中 d 是深度，而 是每個序列的活動數目。 這些方程式的邏輯是，第一個常數乘以 a 是序列數目，而第二個常數是目前層級中的靜態活動數目。 每個流程圖中有三個流程圖子活動。 在底部深度層級，這些流程圖是空的，但在其他層級，它們是主要流程圖的複本。 下表指出每個測試變化工作流程定義中的活動數目：

工作流程定義中的活動數目會隨著每個深度層級大幅增加。 但是每個決策點只會在指定的工作流程實例中執行一個路徑，因此只會執行一小部分的實際活動。

已針對 WF3 建立對等的工作流程。 WF3 設計工具會在設計區域中顯示整個工作流程，而不是巢狀結構，因此無法在本主題中顯示。 工作流程的片段如下所示。

為了在極端情況下練習巢狀結構，此測試的一部分的另一個工作流程會使用100個巢狀序列。 在最內層序列中是一個 Comment 或 CodeActivity。

追蹤和持續性不會當做此測試的一部分使用。

測試結果

即使具有許多深度和大量活動的複雜工作流程，效能結果也會與本文稍早顯示的其他輸送量數位一致。 WF4 的輸送量要快上數個量級，必須在對數刻度上進行比較。

記憶體

Windows Workflow Foundation 的記憶體額外負荷會以兩個主要領域來測量：工作流程複雜度和工作流程定義數目。 記憶體測量是在 Windows 7 64 位工作站上進行的。 有許多方法可以取得工作集大小的測量，例如監視性能計數器、輪詢 Environment.WorkingSet，或使用 VMMap 中可用的 VMMap 之類的工具。 方法的組合可用來取得和驗證每個測試結果。

工作流程複雜度測試

工作流程複雜度測試會根據工作流程的複雜度來測量工作集差異。 除了上一節中使用的複雜工作流程之外，還會新增新的變化來涵蓋兩個基本案例：單一活動工作流程和具有1000個活動的序列。 針對這些測試，工作流程會被初始化並執行至完成，在單一串行迴圈中持續一分鐘。 每個測試變化都會執行三次，而記錄的數據是這三個回合的平均值。

這兩個新的基本測試具有如下所示的工作流程：

在上述 WF3 工作流程中，會使用空 CodeActivity 的活動。 上述 WF4 工作流程會使用 Comment 活動。 此 Comment 活動已在本文稍早的元件層級效能比較一節中說明。

在此圖表中要注意的其中一個明顯趨勢是巢狀結構對WF3和WF4中的記憶體使用量影響相對較小。 最重要的記憶體影響來自指定工作流程中的活動數目。 根據序列 1000、複雜深度 5 的序列 5 以及複雜深度 7 的序列 1 變化的數據，很明顯，當活動數量達到數千個時，記憶體使用量的增加會更加顯著。 在一個極端情況下（深度7的序列1，約有29K個活動），WF4使用的記憶體比WF3少近79%。

多個工作流程定義測試

測量每個工作流程定義的記憶體會分成兩個不同的測試，因為在 WF3 和 WF4 上，設置工作流程時的可用選項各有不同。 測試的執行方式與工作流程複雜度測試的方式不同，因為指定的工作流程會實例化並只執行每個定義一次。 這是因為工作流程定義及其主機會在AppDomain的存留期內保留在記憶體中。 執行指定工作流程實例所使用的記憶體應該在垃圾收集期間清除。 WF4 的移轉指引包含有關主機選項的更詳細資訊。 如需更多資訊，請參閱 WF 遷移指南：工作流程托管。

為工作流程定義測試建立許多工作流程定義，可以透過數種方式來完成。 例如，人們可以使用程式代碼產生來建立一組 1000 個工作流程，這些工作流程的名稱除外，並將每個工作流程儲存到個別的檔案中。 此方法是針對在控制台上進行的測試所採用。 在 WF3 中，類別 WorkflowRuntime 用來執行工作流程定義。 WF4 可以使用 WorkflowApplication 來建立單一工作流程實例，或直接用來 WorkflowInvoker 執行活動，就像是方法呼叫一樣。 WorkflowApplication 是單一工作流程實例的主機，並且具有與 WorkflowRuntime 更接近的相似功能，因此用於此測試。

在 IIS 中裝載工作流程時，可以使用 VirtualPathProvider 來建立新的 WorkflowServiceHost ，而不是產生所有 XAMLX 或 XOML 檔案。 VirtualPathProvider 會處理傳入的請求，並回應一個「虛擬檔案」，這個檔案可以從資料庫載入，或者在這種情況下，立即生成。 因此，不需要建立1000個實體檔案。

控制台測試中使用的工作流程定義是具有單一活動的簡單循序工作流程。 WF3 案例的單一活動是一個空白的CodeActivity，而 WF4 案例則是Comment活動。 IIS 裝載的案例使用在接收訊息時開始的工作流程，並在傳送回復時結束：

下圖顯示具有 ReceiveActivity 的 WF3 工作流程，以及具有要求/回應模式的 WF4 工作流程：

下表顯示單一工作流程定義與 1001 定義之間的工作集變化：

主機選項	WF3 工作集差異	WF4 工作集變化
主控台應用程式內託管的工作流程	18 MB	9 MB
IIS 託管的工作流程服務	446 MB	364 MB

在 IIS 中裝載工作流程定義，由於WorkflowServiceHost、詳細的 WCF 服務工件以及與主機相關聯的訊息處理邏輯，會耗用更多的記憶體。

針對在 WF3 中裝載的控制台，工作流程是在程式代碼中實作，而不是 XOML。 在 WF4 中，預設值是使用 XAML。 XAML 會儲存為元件中的內嵌資源，並在運行時間期間進行編譯，以提供工作流程的實作。 此過程有一些相關聯的額外開銷。 為了在 WF3 和 WF4 之間進行公平比較，會使用程式碼工作流程，而不是 XAML。 其中一個 WF4 工作流程的範例如下所示：

public class Workflow1 : Activity
{
    protected override Func<Activity> Implementation
    {
        get
        {
            return new Func<Activity>(() =>
            {
                return new Sequence
                {
                    Activities = {
                        new Comment()
                    }
                };
            });
        }
        set
        {
            base.Implementation = value;
        }
    }
}

還有其他許多因素會影響記憶體耗用量。 所有 Managed 程式的相同建議仍適用。 在 IIS 托管的環境中，為工作流程定義建立的 WorkflowServiceHost 物件會保留在記憶體中，直到應用程式集區被回收。 撰寫延伸模組時，應該記住這一點。 此外，最好避免「全域」變數（範圍限定於整個工作流程的變數），並盡可能限制變數的範圍。

工作流程執行環境服務

持續性

WF3 和 WF4 都隨附一個 SQL 持久性提供者。 WF3 SQL 持續性提供者是一個簡單的實作，可串行化工作流程實例，並將其儲存在 Blob 中。 基於這個理由，此提供者的效能在很大程度上取決於工作流程實例的大小。 在 WF3 中，實例大小可能會因為許多原因而增加，如本文先前所述。 許多客戶選擇不使用預設 SQL 持續性提供者，因為將串行化實例儲存在資料庫中時，無法檢視工作流程的狀態。 若要在不知道工作流程標識符的情況下尋找特定工作流程，必須還原串行化每個保存的實例，並檢查內容。 許多開發人員偏好撰寫自己的持久性提供者，以克服此障礙。

WF4 SQL 持續性提供者已嘗試解決其中一些疑慮。 持續性數據表會公開特定資訊，例如使用中的書籤和可提升的屬性。 WF4 中以內容為基礎的新相互關聯功能在使用 WF3 SQL 持續性方法時表現不佳，這導致需要更改持續性工作流程實例的組織。 這會使持續性提供者的工作更加複雜，並給資料庫帶來額外的壓力。

環境設定

測試設定

即使使用改良的功能集和更好的並行處理，WF4 中的 SQL 持續性提供者比 WF3 中的提供者更快。 為了展示這一點，在 WF3 和 WF4 中執行基本上相同作業的兩個工作流程會比較如下。

這兩個工作流程都是由收到的訊息所建立。 傳送初始回復之後，工作流程會被持續保存。 在 WF3 案例中，會使用空白 TransactionScopeActivity 來起始持續性。 在 WF3 中，將活動標示為「關閉時持續」即可達到相同的效果。第二個相關的訊息會完成工作流程。 工作流程會保存，但不會卸除。

測試結果

當用戶端和仲介層之間的傳輸為 HTTP 時，WF4 中的持續性會顯示 2.6 倍的改善。 TCP 傳輸會將該因素增加至 3.0 倍。 在所有情況下，中介層的CPU使用率為98% 或更高。 WF4 輸送量較大的原因是工作流程運行時間較快。 這兩個案例的串行化實例大小都很低，在此情況下不是主要貢獻元素。

此測試中的 WF3 和 WF4 工作流程都會使用活動來明確指出何時應該發生持續性。 這有利於保存工作流程，而不需卸載它。 在 WF3 中，也可以使用 TimeToUnload 功能來持續保存，但這會將工作流程實例從記憶體中移除。 如果使用 WF3 的開發人員想要確定工作流程在特定時間點持續存在，他們必須改變工作流程定義，或支付卸除和重新載入工作流程實例的成本。 WF4 中的新功能可讓您在不卸除的情況下將狀態保存：TimeToPersist。 這項功能可讓工作流程實例在閑置時保存，但會保留在記憶體中，直到 TimeToUnload 達到閾值或繼續執行為止。

請注意，WF4 SQL 持續性提供者會在資料庫層中執行更多工作。 SQL 資料庫可能會成為瓶頸，因此請務必監視該處的CPU和磁碟使用量。 當效能測試工作流程應用程式時，請務必包含 SQL 資料庫中的下列性能計數器：

• PhysicalDisk\%Disk 讀取時間

• PhysicalDisk\% 磁碟時間

• PhysicalDisk\% 磁碟寫入時間

• PhysicalDisk\% 平均磁碟佇列長度

• PhysicalDisk\平均磁碟讀取佇列長度

• 磁碟\平均磁碟寫入佇列長度

• PhysicalDisk\目前磁碟佇列長度

• 處理器資訊\% 處理器時間

• SQLServer：Latches\Average Latch Wait Time（ms）

• SQLServer: Latches\鎖存器等待次數/秒

追蹤

工作流程追蹤可用來追蹤工作流程的進度。 追蹤事件中包含的資訊是由追蹤配置檔所決定。 追蹤設定檔越複雜，追蹤成本就越高。

WF3 附帶 SQL 型追蹤服務。 此服務可以分批和非批次模式運作。 在非批次模式中，追蹤事件會直接寫入資料庫。 在批次模式中，追蹤事件會收集到與工作流程實例狀態相同的批次中。 批次模式對於最廣泛的工作流程設計具有最佳效能。 不過，如果工作流程執行許多活動而不保存且追蹤這些活動，批處理可能會對效能造成負面影響。 這通常會在迴圈中發生，而避免此案例的最佳方式是設計大型迴圈以包含持續性點。 將持續性點引入迴圈也會對效能造成負面影響，因此請務必測量每個專案的成本，並取得平衡。

WF4 不包含 SQL 追蹤服務。 將追蹤資訊記錄到 SQL 資料庫可以從應用程式伺服器處理得更好，而不是內建在 .NET Framework 中。 因此，AppFabric 現在會處理 SQL 追蹤。 WF4 中的現用追蹤提供者是以 Windows 事件追蹤 （ETW） 為基礎。

ETW 是 Windows 內建的核心層級低延遲事件系統。 它會使用提供者/取用者模型，使得只有在實際有取用者時，才會對事件追蹤產生懲罰。 除了處理器、磁碟、記憶體和網路使用量等核心事件之外，許多應用程式也會利用 ETW。 ETW 事件比性能計數器更強大，因為事件可以根據應用程式進行自定義。 事件可以包含工作流程標識碼或參考訊息等文字。 此外，事件會分類為位掩碼，讓取用特定事件子集的效能影響會比擷取所有事件少。

使用 ETW 進行追蹤而非 SQL 的方法的優點包括：

• 追蹤事件的集合可以分隔到另一個進程。 這可讓您在記錄事件的方式方面有更大的彈性。

• ETW 追蹤事件可以輕鬆地與 WCF ETW 事件或其他 ETW 提供者結合，例如 SQL Server 或核心提供者。

• 工作流程作者不需要改變工作流程，以更妥善地使用特定的追蹤實作，例如WF3 SQL追蹤服務的批次模式。

• 系統管理員可以在不回收主機程序的情況下開啟或關閉追蹤。

雖然 ETW 追蹤有性能上的優點，但也伴隨著一些缺點。 如果系統承受著巨大的資源壓力，ETW 事件可能會遺失。 事件的處理並非用來封鎖一般程序執行，因此不保證所有 ETW 事件都會廣播給訂閱者。 這可讓 ETW 追蹤非常適合用於健康情況監視，但不適合稽核。

雖然 WF4 沒有 SQL 追蹤提供者，但 AppFabric 會這樣做。 AppFabric 的 SQL 追蹤方法是使用 Windows 服務訂閱 ETW 事件，以批處理事件，並將其寫入專為快速插入而設計的 SQL 數據表。 個別的作業會清空此數據表中的數據，並將它重新設定為可在AppFabric儀錶板上檢視的報告數據表。 這表示會獨立於其來源工作流程處理一批的追蹤事件，因此記錄時不需要等候持久性點。

ETW 事件可以使用logman或 xperf 等工具來記錄。 精簡的 ETL 檔案可以使用 xperfview 之類的工具來檢視，或使用 tracerpt 轉換成更易讀的格式，例如 XML。 在 WF3 中，取得沒有 SQL 資料庫的追蹤事件的唯一選項是建立自定義追蹤服務。 如需 ETW 的詳細資訊，請參閱 WCF 服務和 Windows 事件追蹤和事件追蹤 - Windows 應用程式。

啟用工作流程追蹤會影響不同程度的效能。 下列指標測試使用 logman 工具取用 ETW 追蹤事件，並將其記錄到 ETL 檔案。 AppFabric 中的 SQL 追蹤成本不在本文的範圍內。 用於 AppFabric 的基本追蹤配置檔也顯示在此基準檢驗中。 此外，也包括只追蹤健康情況監視事件的成本。 這些事件適用於針對問題進行疑難解答，並判斷系統的平均輸送量。

環境設定

測試結果

健康情況監視對輸送量的影響大約為 3%。 基本配置檔的成本約為 8%。

Interop

WF4 幾乎是 WF 的完整重寫，因此 WF3 工作流程和活動與 WF4 不直接相容。 許多早期採用 Windows Workflow Foundation 的客戶會有適用於 WF3 的內部或第三方工作流程定義和自定義活動。 輕鬆轉換至 WF4 的其中一種方法是使用 Interop 活動，其可以從 WF4 工作流程內執行 WF3 活動。 建議應只在必要時使用 Interop 活動。 如需移轉至 WF4 的詳細資訊，請參閱 WF4 移轉指引。

環境設定

測試結果

下表顯示執行工作流程的結果，其中包含各種組態中序列中的五個活動。

測試	輸送量（工作流程/秒）
WF3 執行時間中的 WF3 序列	1,576
WF4 運行時間中使用 Interop 的 WF3 時序	二千七百四十五
WF4 序列	153,582

相比於直接使用 WF3，使用 Interop 會有顯著的效能提升。 不過，相較於 WF4 活動，增加是微不足道的。

總結

在 WF4 中，對效能的重點投資在許多關鍵領域得到了回報。 相較於 WF3，個別工作流程元件效能在某些情況下比 WF3 快數百倍，因為 WF 運行時間較精簡。 延遲數據的情況也明顯改善了。 這表示在使用 WF 而不是手寫 WCF 協調流程服務時，考量到使用 WF 所帶來的附加優勢，在效能上的差異非常小。 持久效能已提升至 2.5 到 3 倍。 透過工作流程追蹤進行的健康情況監視現在幾乎沒有額外負荷。 提供完整的移轉指南，供考慮從WF3移至WF4的人士使用。 這一切應該讓WF4成為撰寫複雜應用程式的有吸引力的選項。