Wydajność programu Windows Workflow Foundation 4

Program .NET Framework 4 zawiera ważną poprawkę programu Windows Workflow Foundation (WF) z dużymi inwestycjami w wydajność. Ta nowa rewizja wprowadza znaczące zmiany w konstrukcji od poprzednich wersji WF dostarczanych w ramach .NET Framework 3.0 i .NET Framework 3.5. Został on ponownie zaprojektowany z rdzenia modelu programowania, środowiska uruchomieniowego i narzędzi, aby znacznie poprawić wydajność i użyteczność. W tym temacie przedstawiono ważne cechy wydajności tych poprawek i porównuje je z tymi z poprzedniej wersji.

Wydajność poszczególnych składników przepływu pracy wzrosła o rząd wielkości pomiędzy WF3 a WF4. Pozostawia to lukę między ręcznie kodowanymi usługami Windows Communication Foundation (WCF) a usługami przepływu pracy WCF, która jest dość mała. Opóźnienie przepływu pracy zostało znacznie zmniejszone w programie WF4. Wydajność trwałości wzrosła o współczynnik 2,5 – 3,0. Monitorowanie kondycji za pomocą śledzenia przepływów pracy ma znacznie mniejsze obciążenie. Są to przekonujące powody migracji do lub wdrożenia platformy WF4 w aplikacjach.

Terminologia

Wersja platformy WF wprowadzona w programie .NET Framework 4 będzie określana jako WF4 w pozostałej części tego tematu. Program WF został wprowadzony w programie .NET Framework 3.0 i miał kilka drobnych poprawek za pośrednictwem programu .NET Framework 3.5 SP1. W pozostałej części tego tematu wersja .NET Framework 3.5 dla Workflow Foundation będzie określana jako WF3. WF3 jest dostarczany w środowisku .NET Framework 4 razem z platformą WF4. Aby uzyskać więcej informacji na temat migrowania artefaktów WF3 do platformy WF4, zobacz Przewodnik migracji programu Windows Workflow Foundation 4.

Windows Communication Foundation (WCF) to ujednolicony model programowania firmy Microsoft do tworzenia aplikacji zorientowanych na usługi. Po raz pierwszy został wprowadzony w ramach programu .NET Framework 3.0 wraz z platformą WF3, a teraz jest jednym z kluczowych składników programu .NET Framework.

Windows Server AppFabric to zestaw zintegrowanych technologii, które ułatwiają tworzenie i skalowanie aplikacji internetowych i złożonych uruchamianych w usługach IIS oraz zarządzanie nimi. Udostępnia narzędzia do monitorowania usług i przepływów pracy oraz zarządzania nimi. Aby uzyskać więcej informacji, zobacz Windows Server AppFabric 1.0.

Cele

Celem tego tematu jest przedstawienie cech wydajności platformy WF4 z danymi mierzonymi w różnych scenariuszach. Zawiera również szczegółowe porównania między WF4 i WF3, a tym samym pokazuje wspaniałe ulepszenia wprowadzone w tej nowej wersji. Scenariusze i dane przedstawione w tym artykule kwantyfikują podstawowy koszt różnych aspektów WF4 i WF3. Te dane są przydatne w zrozumieniu cech wydajności platformy WF4 i mogą być przydatne podczas planowania migracji z platformy WF3 do WF4 lub używania platformy WF4 w tworzeniu aplikacji. Należy jednak wziąć pod uwagę wnioski wyciągnięte z danych przedstawionych w tym artykule. Wydajność aplikacji złożonego przepływu pracy jest bardzo zależna od sposobu implementowania przepływu pracy i sposobu integrowania różnych składników. Należy zmierzyć każdą aplikację, aby określić charakterystykę wydajności tej aplikacji.

Omówienie ulepszeń wydajności platformy WF4

WF4 został starannie zaprojektowany i zaimplementowany z wysoką wydajnością i skalowalnością, które opisano w poniższych sekcjach.

Środowisko uruchomieniowe WF

Podstawowym elementem środowiska uruchomieniowego platformy WF jest asynchroniczny harmonogram, który napędza wykonywanie działań w przepływie pracy. Zapewnia wydajne, przewidywalne środowisko wykonawcze dla działań. Środowisko ma dobrze zdefiniowany kontrakt na potrzeby wykonywania, kontynuacji, uzupełniania, anulowania, wyjątków i przewidywalnego modelu wątkowania.

W porównaniu z WF3 środowisko uruchomieniowe WF4 ma bardziej wydajny harmonogram. Wykorzystuje on tę samą pulę wątków wejścia/wyjścia, która jest używana przez WCF, co jest bardzo efektywne przy wykonywaniu grupowych zadań roboczych. Wewnętrzna kolejka harmonogramu elementów roboczych jest zoptymalizowana pod kątem najbardziej typowych wzorców użycia. Środowisko uruchomieniowe WF4 zarządza również stanami wykonywania w bardzo lekki sposób z minimalną logiką synchronizacji i obsługi zdarzeń, podczas gdy WF3 zależy od rejestracji zdarzeń o dużej wadze i wywołania w celu przeprowadzenia złożonej synchronizacji dla przejść stanu.

Magazyn danych i przepływ

W programie WF3 dane skojarzone z działaniem są modelowane za pomocą właściwości zależności implementowanych przez typ DependencyProperty. Wzorzec właściwości zależności został wprowadzony w programie Windows Presentation Foundation (WPF). Ogólnie rzecz biorąc, ten wzorzec jest bardzo elastyczny do obsługi łatwego powiązania danych i innych funkcji interfejsu użytkownika. Jednak wzorzec wymaga, aby właściwości zostały zdefiniowane jako pola statyczne w definicji przepływu pracy. Za każdym razem, gdy środowisko uruchomieniowe WF ustawia lub pobiera wartości właściwości, wiąże się to ze znaczącą logiką wyszukiwania.

WF4 używa jasnej logiki określania zakresu danych, aby znacznie poprawić sposób obsługi danych w przepływie pracy. Oddziela dane przechowywane w działaniu od danych przepływających przez granice działań przy użyciu dwóch różnych pojęć: zmiennych i argumentów. Stosując przejrzysty zakres hierarchiczny dla zmiennych i argumentów "Wejście/Wyjście/Wejście-Wyjście", złożoność użycia danych w działaniach jest znacznie zmniejszona, a czas życia danych również automatycznie ograniczony. Działania mają dobrze zdefiniowaną sygnaturę opisaną przez ich argumenty. Po prostu sprawdzając działanie, możesz określić, jakie dane mają zostać odebrane, i jakie dane zostaną wygenerowane w wyniku jego wykonania.

W programie WF3 działania zostały zainicjowane podczas tworzenia przepływu pracy. W programie WF 4 działania są inicjowane tylko wtedy, gdy są wykonywane odpowiednie działania. Pozwala to na prostszy cykl życia działania bez konieczności wykonywania operacji inicjowania/deinicjowania podczas tworzenia nowego wystąpienia przepływu pracy, co w efekcie zwiększa wydajność.

Sterowanie przepływem

Podobnie jak w każdym języku programowania platforma WF zapewnia obsługę przepływów sterowania dla definicji przepływu pracy, wprowadzając zestaw działań przepływu sterowania na potrzeby sekwencjonowania, pętli, rozgałęziania i innych wzorców. W WF3, gdy to samo działanie musi zostać ponownie wykonane, zostanie utworzony nowy ActivityExecutionContext, a działanie jest klonowane za pomocą ciężkiego procesu serializacji i deserializacji logiki opartej na BinaryFormatter. Zwykle wydajność przepływów sterowania iteracyjnego jest znacznie wolniejsza niż wykonywanie sekwencji działań.

WF4 obsługuje to zupełnie inaczej. Przyjmuje szablon działania, tworzy nowy obiekt ActivityInstance i dodaje go do kolejki harmonogramu. Cały ten proces obejmuje tylko jawne tworzenie obiektów i jest bardzo lekki.

Programowanie asynchroniczne

Aplikacje zwykle mają lepszą wydajność i skalowalność z programowaniem asynchronicznym na potrzeby długotrwałych operacji blokowania, takich jak operacje we/wy lub operacje przetwarzania rozproszonego. Platforma WF4 zapewnia asynchroniczne wsparcie za pośrednictwem podstawowych typów AsyncCodeActivitydziałań , AsyncCodeActivity<TResult>. Środowisko uruchomieniowe natywnie rozumie działania asynchroniczne i dlatego może automatycznie umieścić wystąpienie w strefie nietrwałej, gdy asynchroniczna praca jest w toku. Działania niestandardowe mogą pochodzić z tych typów w celu wykonywania pracy asynchronicznej bez przechowywania wątku harmonogramu przepływu pracy i blokowania wszelkich działań, które mogą być uruchamiane równolegle.

Komunikacja

Początkowo WF3 miał bardzo ograniczone wsparcie dla przesyłania komunikatów poprzez zdarzenia zewnętrzne lub wywołania usług internetowych. W .NET Framework 3.5 przepływy pracy mogły być implementowane jako klienci WCF lub udostępniane jako usługi WCF za pomocą SendActivity i ReceiveActivity. W programie WF4 koncepcja programowania komunikatów opartych na przepływie pracy została jeszcze bardziej wzmocniona dzięki ścisłej integracji logiki obsługi komunikatów WCF z usługą WF.

Ujednolicony potok przetwarzania komunikatów udostępniany w programie WCF na platformie .NET 4 ułatwia usługom WF4 znacznie lepszą wydajność i skalowalność niż WF3. WF4 zapewnia również bogatszą obsługę programowania komunikatów, które mogą modelować złożone wzorce wymiany komunikatów (MEPs). Deweloperzy mogą używać kontraktów usług z typami do łatwego programowania lub kontraktów usług bez typów w celu uzyskania lepszej wydajności bez płacenia kosztów serializacji. Obsługa buforowania kanałów po stronie klienta za pośrednictwem SendMessageChannelCache klasy WF4 ułatwia deweloperom tworzenie szybkich aplikacji przy minimalnym nakładzie pracy. Aby uzyskać więcej informacji, zobacz Zmienianie poziomów udostępniania pamięci podręcznej dla działań wysyłania.

Programowanie deklaratywne

Platforma WF4 zapewnia czystą i prostą strukturę programowania deklaratywnego do modelowania procesów biznesowych i usług. Model programowania obsługuje w pełni deklaratywną kompozycję działań, bez kodu obok, co znacznie upraszcza tworzenie przepływu pracy. W programie .NET Framework 4 struktura programowania deklaratywnego oparta na języku XAML została ujednolicona w jeden zestaw System.Xaml.dll do obsługi zarówno WPF, jak i WF.

W programie WF4 język XAML zapewnia prawdziwie deklaratywne podejście i umożliwia definicję całego przepływu pracy w znacznikach XML, odwołując się do aktywności i typów utworzonych przy użyciu platformy .NET. Trudno było to zrobić w programie WF3 w formacie XOML bez użycia niestandardowej logiki za pomocą kodu. Nowy stos XAML na platformie .NET 4 ma znacznie lepszą wydajność serializowania/deserializacji artefaktów przepływu pracy i sprawia, że programowanie deklaratywne jest bardziej atrakcyjne i solidne.

Projektant przepływu pracy

W pełni deklaratywna obsługa programowania dla platformy WF4 jawnie nakłada wyższe wymagania dotyczące wydajności czasu projektowania dla dużych przepływów pracy. Projektant przepływu pracy w programie WF4 ma znacznie lepszą skalowalność dla dużych przepływów pracy niż w przypadku platformy WF3. Dzięki obsłudze wirtualizacji interfejsu użytkownika projektant może łatwo załadować duży przepływ pracy 1000 działań w ciągu kilku sekund, chociaż prawie niemożliwe jest załadowanie przepływu pracy kilkuset działań za pomocą projektanta WF3.

Porównania wydajności na poziomie składnika

Ta sekcja zawiera dane dotyczące bezpośrednich porównań między poszczególnymi działaniami w przepływach pracy WF3 i WF4. Kluczowe obszary, takie jak trwałość, mają większy wpływ na wydajność niż poszczególne składniki działania. Ulepszenia wydajności poszczególnych składników w programie WF4 są jednak ważne, ponieważ składniki są teraz wystarczająco szybkie, aby można je było porównać z ręcznie zakodowaną logiką aranżacji. Przykład, którego opisano w następnej sekcji: "Scenariusz kompozycji usług".

Konfiguracja środowiska

Na powyższej ilustracji przedstawiono konfigurację maszyny używaną do pomiaru wydajności na poziomie składnika. Jeden serwer i pięciu klientów połączonych za pośrednictwem jednego interfejsu sieciowego Ethernet 1 Gb/s. Dla łatwych pomiarów serwer jest skonfigurowany do używania jednego rdzenia serwera z dwoma procesorami czterordzeniowymi, działającego na systemie Windows Server 2008 x86. Wykorzystanie procesora systemu jest utrzymywane na poziomie prawie 100%.

Szczegóły testu

WF3 CodeActivity jest prawdopodobnie najprostszą aktywnością, którą można użyć w przepływie pracy WF3. Działanie wywołuje metodę w kodzie zaplecza, w którym programista przepływu pracy może dodać niestandardowy kod. W programie WF4 nie ma bezpośredniego odpowiednika WF3 CodeActivity , który zapewnia tę samą funkcjonalność. Należy pamiętać, że istnieje klasa bazowa CodeActivity w WF4, która nie jest powiązana z WF3 CodeActivity. Autorzy przepływów pracy są zachęcani do tworzenia niestandardowych działań i tworzenia przepływów pracy tylko w języku XAML. W poniższych testach działanie o nazwie Comment jest używane zamiast pustego CodeActivity w przepływach pracy WF4. Kod w aktywności Comment jest zgodny z poniższym:

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

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

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Pusty przepływ pracy

Test ten używa sekwencyjnego przepływu pracy bez działań podrzędnych.

Jedno działanie

Przepływ pracy to sekwencja zawierająca jedną aktywność podrzędną. Działanie w przypadku WF3 jest bez CodeActivity kodu, a w przypadku WF4 jest Comment działaniem.

Przy 1000 iteracjach

Przepływ pracy sekwencji zawiera jedno While działanie z jednym działaniem podrzędnym w pętli, które nie wykonuje żadnej pracy.

Replikator w porównaniu z ParallelForEach

ReplicatorActivity w WF3 ma tryby wykonywania sekwencyjnego i równoległego. W trybie sekwencyjnym wydajność aktywności jest podobna do WhileActivity. ReplicatorActivity jest najbardziej przydatne do wykonywania równoległego. Analogiem WF4 dla tego jest czynność ParallelForEach<T>.

Na poniższym diagramie przedstawiono przepływy pracy używane na potrzeby tego testu. Przepływ pracy WF3 znajduje się po lewej stronie, a przepływ pracy WF4 znajduje się po prawej stronie.

Sekwencyjny przepływ pracy z pięcioma działaniami

Ten test ma na celu pokazanie wpływu wykonywania kilku działań w sekwencji. Istnieje pięć działań w sekwencji.

Zakres transakcji

Test zakresu transakcji różni się nieznacznie od innych testów, ponieważ nowe wystąpienie przepływu pracy nie jest tworzone dla każdej iteracji. Zamiast tego przepływ pracy jest ustrukturyzowany za pomocą pętli while zawierającej TransactionScope działanie zawierające jedno działanie, które nie działa. Każde uruchomienie zestawu 50 iteracji przez pętlę while jest liczone jako pojedyncza operacja.

Wynagrodzenie

Przepływ pracy WF3 ma jedno działanie podlegające rekompensacie o nazwie WorkScope. Działanie po prostu implementuje ICompensatableActivity interfejs:

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

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

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

Procedura obsługi błędów jest przeznaczona dla WorkScope działania. Przepływ pracy WF4 jest równie uproszczony. Element CompensableActivity ma ciało i procedurę obsługi odszkodowań. Jawna rekompensata jest kolejnym elementem w sekwencji. Aktywność ciała i aktywność obsługi kompensacji są obie pustymi implementacjami.

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) { }
    }

Na poniższym diagramie przedstawiono podstawowy przepływ pracy kompensacji. Przepływ pracy WF3 znajduje się po lewej stronie, a przepływ pracy WF4 znajduje się po prawej stronie.

Wyniki testu wydajnościowego

Wszystkie testy są mierzone w przepływach pracy na sekundę z wyjątkiem testu zakresu transakcji. Jak widać powyżej, wydajność środowiska uruchomieniowego WF poprawiła się we wszystkich aspektach, zwłaszcza w obszarach wymagających wielokrotnego wykonania tej samej czynności, takiej jak pętla while.

Scenariusz kompozycji usług

Jak pokazano w poprzedniej sekcji, "Porównanie wydajności na poziomie składników", nastąpił znaczny spadek obciążenia między WF3 i WF4. Usługi przepływu pracy WCF mogą teraz niemal odpowiadać wydajności ręcznie kodowanych usług WCF, ale nadal mają wszystkie zalety środowiska uruchomieniowego WF. Ten scenariusz testowy porównuje usługę WCF z usługą przepływu pracy WCF w programie WF4.

Usługa sklepu online

Jedną z zalet programu Windows Workflow Foundation jest możliwość tworzenia procesów przy użyciu kilku usług. W tym przykładzie istnieje usługa sklepu online, która koordynuje dwa wywołania usługi, aby zrealizować zamówienie. Pierwszym krokiem jest zweryfikowanie zamówienia przy użyciu usługi sprawdzania poprawności zamówienia. Drugim krokiem jest wypełnienie zamówienia przy użyciu usługi magazynu.

Dwie usługi zaplecza, Order Validating Service i Warehouse Service, pozostają takie same dla obu testów. Część, która zmienia się, to usługa sklepu online, która wykonuje aranżację. W jednym przypadku usługa jest ręcznie kodowana jako usługa WCF. W innym przypadku usługa jest zapisywana jako usługa przepływu pracy WCF w programie WF4. Funkcje specyficzne dla platformy WF, takie jak śledzenie i trwałość, są wyłączone na potrzeby tego testu.

Środowisko

Żądania klientów są wysyłane do usługi sklepu online za pośrednictwem protokołu HTTP z wielu komputerów. Jeden komputer hostuje wszystkie trzy usługi. Warstwa transportu między usługą sklepu online a usługami zaplecza to TCP lub HTTP. Pomiar operacji na sekundę jest oparty na liczbie ukończonych wywołań do usługi sklepu internetowego. Buforowanie kanałów to nowa funkcja dostępna w oprogramowaniu WF4. W części dotyczącej WCF tego testu nie jest od razu dostępne korzystanie z buforowania kanałów, dlatego użyto ręcznie zakodowanej implementacji prostej techniki buforowania w Usłudze Sklepu Internetowego.

Wydajność

Łączenie z usługami TCP zaplecza bez użycia puli kanałów powoduje, że usługa WF wpływa na przepustowość o 17.2%. W przypadku łączenia kanałów kara wynosi około 23,8%. W przypadku protokołu HTTP wpływ jest znacznie mniejszy: 4,3% bez buforowania i 8,1% z buforowaniem. Należy również pamiętać, że buforowanie kanałów zapewnia bardzo małą korzyść podczas korzystania z protokołu HTTP.

Chociaż w tym teście występuje obciążenie związane ze środowiskiem uruchomieniowym WF4 w porównaniu z ręcznie zakodowaną usługą WCF, można ją uznać za najgorszy scenariusz. Dwie usługi zaplecza w tym teście wykonują bardzo mało pracy. W rzeczywistym scenariuszu kompleksowe usługi te wykonują droższe operacje, takie jak wywołania bazy danych, co sprawia, że wpływ warstwy transportu na wydajność jest mniej ważny. Ponadto zalety funkcji dostępnych w programie WF4 sprawiają, że program Workflow Foundation jest realnym wyborem do tworzenia usług orkiestracji.

Najważniejsze zagadnienia dotyczące wydajności

Obszary funkcji w tej sekcji, z wyjątkiem interoperacyjności, znacznie zmieniły się między WF3 a WF4. Ma to wpływ na projektowanie aplikacji przepływu pracy oraz wydajność.

Opóźnienie aktywacji przepływu pracy

W aplikacji usługi przepływu pracy WCF opóźnienie uruchamiania nowego przepływu pracy lub ładowania istniejącego przepływu pracy jest ważne, ponieważ może być blokowane. Ten przypadek testowy mierzy hosta XOML WF3 względem hosta XAMLX WF4 w typowym scenariuszu.

Konfiguracja środowiska

Konfiguracja testu

W scenariuszu komputer kliencki kontaktuje się z usługą przepływu pracy WCF przy użyciu korelacji opartej na kontekście. Korelacja kontekstu wymaga specjalnego wiązania kontekstu i używa nagłówka kontekstu lub pliku cookie w celu powiązania komunikatów z odpowiednim wystąpieniem przepływu pracy. Ma ona korzyść z wydajności, ponieważ identyfikator korelacji znajduje się w nagłówku komunikatu, więc treść komunikatu nie musi być analizowana.

Usługa utworzy nowy przepływ pracy z żądaniem i wyśle natychmiastową odpowiedź, aby pomiar opóźnienia nie obejmował czasu spędzonego na uruchomieniu przepływu pracy. Przepływ pracy WF3 to XOML z kodem, a przepływ pracy WF4 jest całkowicie XAML. Przepływ pracy WF4 wygląda następująco:

Działanie Receive tworzy wystąpienie przepływu pracy. Wartość przekazana w odebranej wiadomości jest powtarzana w komunikacie odpowiedzi. Sekwencja po odpowiedzi zawiera pozostałą część przepływu pracy. W powyższym przypadku wyświetlana jest tylko jedna aktywność komentarza. Liczba działań komentarzy została zmieniona w celu symulowania złożoności przepływu pracy. Aktywność komentarza jest równoważna z WF3 CodeActivity, który nie wykonuje żadnej pracy. Aby uzyskać więcej informacji na temat działania komentarzy, zobacz sekcję "Porównanie wydajności na poziomie składnika" we wcześniejszej części tego artykułu.

Wyniki testu

Zimne i ciepłe opóźnienie dla usług przepływu pracy WCF:

Na poprzednim wykresie zimny odnosi się do przypadku, w którym nie ma istniejącej WorkflowServiceHost dla danego przepływu pracy. Innymi słowy, zimne opóźnienie jest wtedy, gdy przepływ pracy jest używany po raz pierwszy, a XOML lub XAML należy skompilować. Ciepłe opóźnienie to czas utworzenia nowego wystąpienia przepływu pracy, gdy typ przepływu pracy został już skompilowany. Złożoność przepływu pracy ma bardzo małą różnicę w przypadku WF4, ale ma liniowy postęp w przypadku WF3.

Przepływność korelacji

WF4 wprowadza nową funkcję korelacji opartą na zawartości. WF3 dostarczył tylko korelację opartą na kontekście. Korelacja oparta na kontekście może być wykonywana tylko w przypadku określonych powiązań kanału WCF. Identyfikator przepływu pracy jest wstawiany do nagłówka komunikatu podczas korzystania z tych powiązań. Środowisko uruchomieniowe WF3 może zidentyfikować tylko przepływ pracy według jego identyfikatora. Dzięki korelacji opartej na zawartości autor przepływu pracy może utworzyć klucz korelacji z odpowiedniego elementu danych, takiego jak numer konta lub identyfikator klienta.

Korelacja oparta na kontekście ma przewagę wydajności w tym, że klucz korelacji znajduje się w nagłówku komunikatu. Klucz można odczytać z komunikatu bez deserializacji/kopiowania wiadomości. W korelacji opartej na zawartości klucz korelacji jest przechowywany w treści komunikatu. Wyrażenie XPath służy do lokalizowania klucza. Koszt tego dodatkowego przetwarzania zależy od rozmiaru komunikatu, głębokości klucza w treści i liczby kluczy. Ten test porównuje korelację kontekstową i opartą na zawartości, a także pokazuje spadek wydajności podczas korzystania z wielu kluczy.

Konfiguracja środowiska

Konfiguracja testu

Poprzedni przepływ pracy jest taki sam, jak używany w sekcji Trwałość . W przypadku testów korelacji bez trwałości nie ma zainstalowanego dostawcy trwałości w środowisku uruchomieniowym. Korelacja występuje w dwóch miejscach: CreateOrder i CompleteOrder.

Wyniki testu

Ten wykres przedstawia spadek wydajności w miarę wzrostu liczby kluczy używanych w korelacji opartej na zawartości. Podobieństwo w krzywych między protokołami TCP i HTTP wskazuje obciążenie związane z tymi protokołami.

Korelacja z trwałością

W przypadku utrwalonego przepływu pracy ciśnienie procesora CPU z korelacji opartej na treści zmienia się ze środowiska uruchomieniowego przepływu pracy na bazę danych SQL. Procedury przechowywane w dostawcy trwałości SQL wykonują pracę dopasowywania kluczy w celu zlokalizowania odpowiedniego workflowu.

Korelacja oparta na kontekście jest nadal szybsza niż korelacja oparta na zawartości. Różnica jest jednak mniej widoczna, ponieważ trwałość ma większy wpływ na wydajność niż korelacja.

Złożona przepływność przepływu pracy

Złożoność przepływu pracy nie jest mierzona tylko przez liczbę działań. Działania złożone mogą zawierać wiele działań podrzędnych, a te działania podrzędne mogą być również działaniami złożonymi. W miarę zwiększania się liczby poziomów zagnieżdżenia, wzrasta liczba działań, które mogą być obecnie w stanie wykonywania, oraz liczba zmiennych, które mogą być w stanie aktywnym. Ten test porównuje przepływność między WF3 i WF4 podczas wykonywania złożonych przepływów pracy.

Konfiguracja testu

Te testy zostały wykonane na komputerze Intel Xeon X5355 @ 2.66GHz 4-way z 4 GB pamięci RAM z systemem Windows Server 2008 x64. Kod testowy jest uruchamiany w jednym procesie z jednym wątkiem na rdzeń, aby osiągnąć 100% wykorzystania procesora CPU.

Przepływy pracy wygenerowane dla tego testu mają dwie główne zmienne: głębokość i liczbę działań w każdej sekwencji. Każdy poziom głębokości obejmuje równoległą aktywność, pętlę, decyzje, przypisania i sekwencje. W projektancie WF4 na zdjęciu poniżej przedstawiono wykres blokowy najwyższego poziomu. Każda czynność w schemacie blokowym przypomina główny schemat blokowy. Warto pomyśleć o fraktalu podczas wyobrażania sobie tego procesu roboczego, gdzie głębokość jest ograniczona do parametrów testu.

Liczba działań w danym teście jest określana przez głębokość i liczbę działań na sekwencję. Następujące równanie oblicza liczbę działań w teście WF4:

Liczbę działań testu WF3 można obliczyć z nieco innym równaniem z powodu dodatkowej sekwencji:

Gdzie d to głębokość i liczba działań na sekwencję. Logika za tymi równaniami polega na tym, że pierwsza stała, pomnożona przez element , jest liczbą sekwencji, a druga stała jest statyczną liczbą działań na bieżącym poziomie. W każdym schemacie blokowym istnieją trzy działania podrzędne schematu blokowego. Na najniższym poziomie głębokości te diagramy blokowe są puste, ale na innych poziomach są kopiami głównego diagramu blokowego. Liczba działań w definicji przepływu pracy odmiany testów jest wskazana w poniższej tabeli:

Liczba działań w definicji przepływu pracy gwałtownie wzrasta wraz z każdym poziomem głębokości. Jednak tylko jedna ścieżka w punkcie decyzyjnym jest wykonywana w danym wystąpieniu przepływu pracy, więc wykonywany jest tylko mały podzbiór realnych działań.

Równoważny przepływ pracy został utworzony dla platformy WF3. Projektant WF3 wyświetla cały przepływ pracy w obszarze projektowania zamiast zagnieżdżania elementów, w związku z tym jest zbyt duży, żeby go wyświetlić w tym temacie. Poniżej przedstawiono fragment kodu przepływu pracy.

Aby wykonać zagnieżdżanie w skrajnym przypadku, inny przepływ pracy, który jest częścią tego testu, używa 100 zagnieżdżonych sekwencji. W najbardziej wewnętrznej sekwencji jest pojedynczy Comment lub CodeActivity.

Śledzenie i trwałość nie są używane w ramach tego testu.

Wyniki testu

Nawet w przypadku złożonych przepływów pracy z dużą głębokością i dużą liczbą działań wyniki wydajności są zgodne z innymi liczbami przepływności przedstawionymi wcześniej w tym artykule. Przepływność WF4 jest znacznie szybsza i musi być porównywana w skali logarytmicznej.

Pamięć

Obciążenie pamięcią programu Windows Workflow Foundation jest mierzone w dwóch kluczowych obszarach: złożoność przepływu pracy i liczba definicji przepływu pracy. Pomiary pamięci zostały wykonane na 64-bitowej stacji roboczej z systemem Windows 7. Istnieje wiele sposobów uzyskiwania pomiaru rozmiaru zestawu roboczego, takich jak monitorowanie liczników wydajności, sondowanie środowiska.WorkingSet lub korzystanie z narzędzia, takiego jak VMMap dostępne na platformie VMMap. Użyto kombinacji metod w celu uzyskania i zweryfikowania wyników każdego testu.

Test złożoności przepływu pracy

Test złożoności przepływu pracy mierzy różnicę zestawu roboczego na podstawie złożoności przepływu pracy. Oprócz złożonych przepływów pracy używanych w poprzedniej sekcji, dodawane są nowe odmiany, które obejmują dwa podstawowe przypadki: przepływ pracy składający się z jednego działania i sekwencję 1000 działań. W przypadku tych testów przepływy pracy są inicjowane i wykonywane do ukończenia w jednej pętli szeregowej przez okres jednej minuty. Każda odmiana testu jest uruchamiana trzy razy, a zarejestrowane dane to średnia z tych trzech przebiegów.

Dwa nowe podstawowe testy mają przepływy pracy, które wyglądają podobnie do poniższych:

W powyższym przepływie pracy WF3 są używane puste CodeActivity aktywności. Powyższy przepływ pracy WF4 używa Comment działań. Działanie Comment zostało opisane w sekcji Porównanie wydajności na poziomie składnika we wcześniejszej części tego artykułu.

Jednym z wyraźnych trendów, które należy zauważyć na tym wykresie, jest to, że zagnieżdżanie ma stosunkowo minimalny wpływ na użycie pamięci zarówno w WF3, jak i WF4. Najbardziej znaczący wpływ na pamięć wynika z liczby działań w danym przepływie pracy. Biorąc pod uwagę dane z sekwencji o złożoności 1000, złożoności 5 poziomu 5 oraz złożoności 7 poziomu 1, jasne jest, że gdy liczba działań osiąga tysiące, wzrost użycia pamięci staje się bardziej zauważalny. W skrajnym przypadku (głębokość 7 sekwencji 1), gdzie występują działania ~29K, WF4 używa prawie 79% mniej pamięci niż WF3.

Test wielu definicji przepływu pracy

Mierzenie pamięci na definicję przepływu pracy jest podzielone na dwa różne testy ze względu na dostępne opcje hostowania przepływów pracy w WF3 i WF4. Testy są uruchamiane w inny sposób niż test złożoności przepływu pracy, ponieważ dany przepływ pracy jest tworzony jako instancja i wykonywany tylko raz na definicję. Dzieje się tak, ponieważ definicja przepływu pracy i jego host pozostają w pamięci przez okres istnienia domeny aplikacji. Pamięć używana przez uruchomioną instancję danego przepływu pracy powinna być wyczyszczona podczas zbierania śmieci. Wskazówki dotyczące migracji dla platformy WF4 zawierają bardziej szczegółowe informacje na temat opcji hostingu. Aby uzyskać więcej informacji, zobacz Podręcznik migracji WF: Hosting przepływu pracy.

Tworzenie wielu definicji przepływu pracy dla testu definicji przepływu pracy można wykonać na kilka sposobów. Można na przykład użyć generowania kodu, aby utworzyć zestaw 1000 przepływów pracy, które są identyczne, z wyjątkiem nazwy i zapisać każdy z tych przepływów pracy w oddzielnych plikach. Ta metoda została podjęta w przypadku testu hostowanego w konsoli. W programie WF3 klasa została użyta WorkflowRuntime do uruchamiania definicji przepływu pracy. WF4 może użyć WorkflowApplication do utworzenia pojedynczego wystąpienia przepływu pracy lub użyć bezpośrednio WorkflowInvoker do uruchomienia działania, tak jakby było to wywołanie metody. WorkflowApplication jest hostem pojedynczego wystąpienia przepływu pracy i ma bliższą porównywalność funkcji do WorkflowRuntime, dlatego został użyty w tym teście.

W przypadku hostowania przepływów pracy w IIS można użyć VirtualPathProvider, aby utworzyć nową WorkflowServiceHost zamiast generować wszystkie pliki XAMLX lub XOML. Obiekt VirtualPathProvider obsługuje żądanie przychodzące i odpowiada za pomocą "pliku wirtualnego", który można załadować z bazy danych lub, w tym przypadku, wygenerowany na bieżąco. W związku z tym tworzenie 1000 plików fizycznych jest niepotrzebne.

Definicje przepływu pracy używane w teście konsoli były prostymi sekwencyjnymi przepływami pracy z jednym działaniem. Pojedynczą czynnością było puste CodeActivity w przypadku WF3 oraz działanie Comment w przypadku WF4. Przypadek hostowany przez usługi IIS używał przepływów pracy, które zaczynają się od odebrania komunikatu i kończą się na wysłaniu odpowiedzi.

Na poniższej ilustracji przedstawiono przepływ pracy platformy WF3 z funkcją ReceiveActivity i przepływem pracy WF4 ze wzorcem żądania/odpowiedzi:

W poniższej tabeli przedstawiono różnicę w zestawie roboczym między pojedynczą definicją przepływu pracy a definicjami 1001:

Opcje hostingu	Delta zestawu roboczego WF3	Zestaw roboczy WF4 Delta
Hostowane przepływy pracy aplikacji konsolowej	18 MB	9 MB
Usługi przepływu pracy hostowanego przez usługi IIS	446 MB	364 MB

Hosting definicji przepływu pracy w IIS zużywa znacznie więcej pamięci ze względu na WorkflowServiceHost, szczegółowe artefakty usługi WCF i logikę przetwarzania komunikatów skojarzoną z hostem.

W przypadku hostowania konsoli w programie WF3 przepływy pracy zostały zaimplementowane w kodzie zamiast XOML. W programie WF4 ustawieniem domyślnym jest użycie języka XAML. Kod XAML jest przechowywany jako zasób osadzony w zestawie i kompilowany podczas wykonywania w celu zapewnienia implementacji przepływu pracy. Istnieje pewne obciążenie związane z tym procesem. Aby dokonać sprawiedliwego porównania między WF3 i WF4, kodowane przepływy pracy były używane zamiast XAML. Poniżej przedstawiono przykład jednego z przepływów pracy platformy 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;
        }
    }
}

Istnieje wiele innych czynników, które mogą mieć wpływ na zużycie pamięci. Te same porady dla wszystkich programów zarządzanych nadal mają zastosowanie. W środowiskach hostowanych przez usługi IIS obiekt utworzony dla definicji przepływu pracy pozostaje w pamięci, dopóki pula aplikacji nie zostanie zrestartowana. Należy pamiętać o tym podczas pisania rozszerzeń. Ponadto najlepiej unikać zmiennych globalnych (zmiennych o zakresie całego przepływu pracy) i ograniczyć zakres zmiennych wszędzie tam, gdzie to możliwe.

Usługi środowiska uruchomieniowego przepływu pracy

Wytrwałość

Zarówno WF3, jak i WF4 są dostarczane z dostawcą persystencji SQL. Dostawca trwałości SQL WF3 to prosta implementacja, która serializuje wystąpienie przepływu pracy i przechowuje je w obiekcie blob. Z tego powodu wydajność tego dostawcy zależy w dużym stopniu od rozmiaru wystąpienia przepływu pracy. W programie WF3 rozmiar wystąpienia może wzrosnąć z wielu powodów, jak omówiono wcześniej w tym dokumencie. Wielu klientów decyduje się nie używać domyślnego dostawcy trwałości SQL, ponieważ przechowywanie serializowanego wystąpienia w bazie danych nie daje wglądu w stan przepływu pracy. Aby znaleźć określony przepływ pracy bez znajomości identyfikatora przepływu pracy, należy zdeserializować każde utrwalone wystąpienie i zbadać jego zawartość. Wielu deweloperów woli tworzyć własne mechanizmy trwałości, aby pokonać tę przeszkodę.

Dostawca trwałości SQL WF4 próbował rozwiązać niektóre z tych problemów. Tabele trwałości uwidaczniają pewne informacje, takie jak aktywne zakładki i właściwości promowalne. Nowa funkcja korelacji oparta na zawartości w programie WF4 nie działa dobrze przy stosowaniu metod persystencji SQL z WF3, co doprowadziło do zmian w strukturze utrwalonego wystąpienia przepływu pracy. Sprawia to, że zadanie dostawcy trwałości jest bardziej złożone i wywiera dodatkowy nacisk na bazę danych.

Konfiguracja środowiska

Konfiguracja testu

Nawet w przypadku ulepszonego zestawu funkcji i lepszej obsługi współbieżności dostawca trwałości SQL w programie WF4 jest szybszy niż dostawca w programie WF3. Aby to pokazać, dwa przepływy pracy, które wykonują zasadniczo te same operacje w WF3 i WF4, są porównywane poniżej.

Oba przepływy pracy są tworzone przez odebrany komunikat. Po wysłaniu początkowej odpowiedzi przepływ pracy zostaje zachowany. W przypadku WF3 pusta TransactionScopeActivity jest używana do inicjowania trwałości. To samo można osiągnąć w WF3, oznaczając aktywność jako "utrwal na zamknięciu". Druga, skorelowana wiadomość kończy przepływ pracy. Przepływy pracy są zapisywane, ale nie są usuwane z pamięci.

Wyniki testu

Gdy transport między klientem a warstwą środkową odbywa się przez HTTP, wydajność trwałości w WF4 wzrosła 2,6-krotnie. Transport TCP zwiększa ten współczynnik do 3,0 razy. We wszystkich przypadkach wykorzystanie CPU w warstwie środkowej wynosi 98% lub więcej. Powodem większej przepływności WF4 jest szybszy czas wykonania przepływu pracy. Rozmiar serializowanego wystąpienia jest niski w obu przypadkach i nie stanowi istotnego czynnika w tej sytuacji.

Zarówno przepływy pracy WF3, jak i WF4 w tym teście używają działania, aby jawnie wskazać, kiedy powinna wystąpić trwałość. Ma to tę korzyść, że przepływ pracy jest zachowywany bez jego rozładowywania. W WF3 można również zapisywać przy użyciu funkcji TimeToUnload, ale zwalnia to wystąpienie przepływu pracy z pamięci. Jeśli deweloper korzystający z WF3 chce upewnić się, że przepływ pracy będzie trwał w określonych punktach, musi zmienić definicję przepływu pracy lub ponieść koszty związane z usunięciem i ponownym załadowaniem wystąpienia przepływu pracy. Nowa funkcja w programie WF4 umożliwia utrwalanie bez zwalniania: TimeToPersist. Ta funkcja pozwala na zapisywanie instancji przepływu pracy podczas bezczynności, ale utrzymuje ją w pamięci, dopóki TimeToUnload próg nie zostanie osiągnięty lub wykonanie zostanie wznowione.

Należy pamiętać, że dostawca trwałości SQL WF4 wykonuje więcej pracy w warstwie bazy danych. Baza danych SQL może stać się wąskim gardłem, dlatego ważne jest, aby monitorować użycie procesora CPU i dysku. Pamiętaj, aby uwzględnić następujące liczniki wydajności z bazy danych SQL podczas testowania wydajności aplikacji przepływu pracy:

• PhysicalDisk\%Disk Czas Odczytu

• Dysk fizyczny\% czas pracy dysku

• Dysk fizyczny\% czas zapisu dysku

• PhysicalDisk\% średnia długość kolejki dysku

• PhysicalDisk\Średnia długość kolejki odczytu dysku

• PhysicalDisk\Średnia długość kolejki zapisu dysku

• PhysicalDisk\Bieżąca długość kolejki dysku

• Informacje o procesorze\ czas procesora%

• SQLServer:Latches\Średni czas oczekiwania na zatrzask (ms)

• SQLServer:Zatrzaski\Czekanie na zatrzasków/sek (Latch Waits/sec)

Śledzenie

Śledzenie przepływu pracy może służyć do śledzenia postępu przepływu pracy. Informacje zawarte w zdarzeniach śledzenia są określane przez profil śledzenia. Im bardziej złożony profil śledzenia, tym droższe staje się śledzenie.

WF3 dostarczany z usługą śledzenia opartą na języku SQL. Ta usługa może działać w trybie wsadowym i nie-wsadowym. W trybie bezpakietowym zdarzenia śledzenia są zapisywane bezpośrednio w bazie danych. W trybie wsadowym zdarzenia śledzenia są zbierane w tym samym pakiecie co stan instancji przepływu pracy. Tryb wsadowy ma najlepszą wydajność dla najszerszego zakresu projektów przepływów pracy. Jednak przetwarzanie wsadowe może mieć negatywny wpływ na wydajność, jeśli przepływ pracy uruchamia wiele działań bez utrwalania i śledzone są te działania. Często zdarza się to w pętlach i najlepszym sposobem uniknięcia tego scenariusza jest zaprojektowanie dużych pętli w taki sposób, aby zawierały punkt trwałości. Wprowadzenie punktu trwałości do pętli może negatywnie wpłynąć na wydajność, dlatego ważne jest, aby zmierzyć koszty poszczególnych elementów i wymyślić równowagę.

WF4 nie jest dostarczany z usługą śledzenia SQL. Rejestrowanie informacji śledzenia w bazie danych SQL może być lepiej obsługiwane z serwera aplikacji, a nie wbudowane w program .NET Framework. W związku z tym śledzenie SQL jest teraz obsługiwane przez aplikację AppFabric. Domyślny dostawca śledzenia w WF4 jest oparty na śledzeniu zdarzeń dla systemu Windows (ETW).

ETW to system zdarzeń niskiego opóźnienia na poziomie jądra wbudowany w system Windows. Korzysta z modelu dostawcy/konsumenta, który umożliwia naliczanie kary tylko za śledzenie zdarzeń, gdy istnieje użytkownik. Oprócz zdarzeń jądra, takich jak procesor, dysk, pamięć i użycie sieci, wiele aplikacji korzysta również z funkcji ETW. Zdarzenia ETW są potężniejsze niż liczniki wydajności, ponieważ można je dostosować do aplikacji. Zdarzenie może zawierać tekst, taki jak identyfikator przepływu pracy lub komunikat informacyjny. Ponadto zdarzenia są podzielone na kategorie z maskami bitowymi, dzięki czemu przetwarzanie określonego podzestawu zdarzeń będzie miało mniejszy wpływ na wydajność niż przechwytywanie wszystkich zdarzeń.

Korzyści wynikające z używania funkcji ETW do śledzenia zamiast programu SQL obejmują:

• Zbieranie zdarzeń śledzenia można oddzielić od innego procesu. Zapewnia to większą elastyczność w sposobie rejestrowania zdarzeń.

• Zdarzenia śledzenia ETW można łatwo łączyć ze zdarzeniami ETW WCF lub innymi dostawcami ETW, takimi jak SQL Server lub dostawca jądra.

• Autorzy przepływów pracy nie muszą zmieniać przepływu pracy, aby lepiej pracować z określoną implementacją śledzenia, taką jak tryb wsadowy usługi śledzenia WF3 SQL.

• Administrator może włączyć lub wyłączyć śledzenie bez ponownego uruchamiania procesu hosta.

Śledzenie ETW ma zalety związane z wydajnością, ale wiąże się także z pewnymi wadami. Zdarzenia ETW można utracić, jeśli system znajduje się pod dużym obciążeniem zasobów. Przetwarzanie zdarzeń nie jest przeznaczone do blokowania normalnego wykonywania programu i dlatego nie ma gwarancji, że wszystkie zdarzenia ETW będą emitowane do swoich subskrybentów. Dzięki temu śledzenie ETW jest doskonałym rozwiązaniem do monitorowania zdrowia, ale nie nadaje się do audytu.

Chociaż WF4 nie ma dostawcy śledzenia SQL, AppFabric ma. Podejście programu AppFabric do śledzenia SQL polega na subskrybowaniu zdarzeń ETW za pomocą usługi systemu Windows, która przetwarza zdarzenia wsadowo i zapisuje je w tabeli SQL przeznaczonej do szybkiego wstawiania. Oddzielne zadanie opróżnia dane z tej tabeli i przekształca je w tabele raportowe, które można wyświetlić na pulpicie nawigacyjnym AppFabric. Oznacza to, że zbiór zdarzeń śledzenia jest przetwarzany niezależnie od przepływu pracy, z którego pochodzi, i dlatego nie musi czekać na punkt trwałości przed zarejestrowaniem.

Zdarzenia ETW można rejestrować za pomocą narzędzi, takich jak logman lub xperf. Kompaktowy plik ETL można wyświetlić za pomocą narzędzia, takiego jak xperfview, lub przekonwertować na bardziej czytelny format, taki jak XML, ze tracerpt. W programie WF3 jedyną opcją do śledzenia zdarzeń bez bazy danych SQL jest utworzenie niestandardowej usługi śledzenia. Aby uzyskać więcej informacji na temat funkcji ETW, zobacz Usługi WCF i śledzenie zdarzeń dla systemu Windows i śledzenia zdarzeń — aplikacje systemu Windows.

Włączenie śledzenia przepływu pracy będzie miało wpływ na wydajność w różnym stopniu. Poniższy test porównawczy używa narzędzia logman do obsługi zdarzeń śledzenia ETW i rejestrowania ich w pliku ETL. Koszt śledzenia SQL w programie AppFabric nie znajduje się w zakresie tego artykułu. Podstawowy profil śledzenia, używany również w AppFabric, jest pokazany w tym benchmarku. W koszt wliczone jest także śledzenie tylko zdarzeń monitorowania kondycji zdrowotnej. Te zdarzenia są przydatne do rozwiązywania problemów i określania średniej przepływności systemu.

Konfiguracja środowiska

Wyniki testu

Monitorowanie zdrowia ma około 3% wpływ na przepustowość. Koszt profilu podstawowego wynosi około 8%.

Interoperacyjność

WF4 jest prawie kompletnym ponownym zapisywaniem WF i dlatego przepływy pracy i działania WF3 nie są bezpośrednio zgodne z WF4. Wielu klientów, którzy wcześnie przyjęli program Windows Workflow Foundation, będą mieli definicje przepływu pracy wewnętrznego lub innych firm oraz niestandardowe działania dla platformy WF3. Jednym ze sposobów ułatwienia przejścia do WF4 jest użycie aktywności Interop, która może wykonywać aktywności WF3 w ramach przepływu pracy WF4. Zaleca się stosowanie działania Interop tylko wtedy, gdy jest to konieczne. Aby uzyskać więcej informacji na temat migracji do platformy WF4, zapoznaj się ze wskazówkami dotyczącymi migracji WF4.

Konfiguracja środowiska

Wyniki testu

W poniższej tabeli przedstawiono wyniki uruchamiania przepływu pracy zawierającego pięć działań w sekwencji w różnych konfiguracjach.

Testowanie	Przepływność (przepływy pracy/s)
Sekwencja WF3 w środowisku uruchomieniowym WF3	1,576
Sekwencja WF3 w środowisku uruchomieniowym WF4 przy użyciu programu Interop	2 745
Sekwencja WF4	153,582

Jest zauważalny wzrost wydajności przy użyciu Interop w porównaniu do bezpośredniego WF3. Jednak w porównaniu z działaniami WF4 wzrost jest niewielki.

Podsumowanie

Duże inwestycje w wydajność WF4 opłaciły się w wielu kluczowych obszarach. Wydajność poszczególnych składników przepływu pracy jest w niektórych przypadkach setki razy szybsza w programie WF4 w porównaniu z WF3 ze względu na szczuplejsze środowisko uruchomieniowe WF. Liczby opóźnień są również znacznie lepsze. To oznacza, że strata wydajności związana z korzystaniem z platformy WF, w przeciwieństwie do usług orkiestracji WCF kodowanych ręcznie, jest bardzo mała, biorąc pod uwagę dodatkowe korzyści wynikające z używania platformy WF. Wydajność trwałości wzrosła o współczynnik 2,5 – 3,0. Monitorowanie kondycji za pomocą śledzenia przepływów pracy ma teraz bardzo niewielkie obciążenie. Dostępny jest kompleksowy zestaw przewodników migracji dla osób rozważających przejście z WF3 do WF4. Wszystko to powinno sprawić, że WF4 będzie atrakcyjną opcją do pisania złożonych aplikacji.