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 poprawka wprowadza znaczące zmiany w projekcie z poprzednich wersji programu WF dostarczanych w ramach programów .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 kolejność wielkości między WF3 i WF4. Pozostawia to lukę między ręcznie kodowanym usługami Windows Communication Foundation (WCF) i usługami przepływu pracy WCF, które mają być dość małe. 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 program .NET Framework 3.5 Foundation będzie określany jako WF3. WF3 jest dostarczany w programie .NET Framework 4 obok siebie 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 platform 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 wykonywania 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 we/wy, która jest używana w programie WCF, co jest bardzo wydajne podczas wykonywania wsadowych elementów 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 platformy WF ustawia lub pobiera wartości właściwości, wiąże się to z mocno ważoną 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. Dzięki użyciu jasnego zakresu hierarchicznego dla zmiennych i argumentów "Wyjaś/wyjęcie" złożoność użycia danych dla działań jest znacznie zmniejszona, a okres istnienia danych jest również automatycznie ograniczony. Działania mają dobrze zdefiniowany podpis opisany przez jego 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 wykonywania operacji Inicjowanie/Uninitialize podczas tworzenia nowego wystąpienia przepływu pracy i w związku z tym osiąga większą wydajność

Przepływ sterowania

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 programie WF3, gdy to samo działanie musi zostać ponownie wykonane, zostanie utworzony nowy ActivityExecutionContext , a działanie jest klonowane za pomocą dużej serializacji i deserializacji logiki na BinaryFormatterpodstawie . 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 bez trwałości, podczas gdy praca asynchroniczna jest zaległa. 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.

Obsługa komunikatów

Początkowo WF3 miał bardzo ograniczoną obsługę komunikatów za pośrednictwem zdarzeń zewnętrznych lub wywołań usług internetowych. W programie .NET Framework 3.5 przepływy pracy mogą być implementowane jako klienci WCF lub udostępniane jako usługi WCF za pośrednictwem systemów 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 typowych do łatwego programowania lub bez wpisywania kontraktów usług 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 środowisko i umożliwia zdefiniowanie całej definicji przepływu pracy w adiustacji XML, odwoływanie się do działań 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ływów 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ługi".

Konfigurowanie ś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. W przypadku łatwych pomiarów serwer jest skonfigurowany do używania jednego rdzenia serwera z podwójnym proc/quad-core z systemem Windows Server 2008 x86. Wykorzystanie procesora CPU systemu jest utrzymywane na poziomie prawie 100%.

Szczegóły testu

WF3 CodeActivity jest prawdopodobnie najprostszym działaniem, które może być używane w przepływie pracy WF3. Działanie wywołuje metodę w kodzie, do którego programista przepływu pracy może umieścić 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 Comment działaniu jest następujący:

[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

Ten test używa przepływu pracy sekwencji bez działań podrzędnych.

Jedno działanie

Przepływ pracy to przepływ pracy sekwencji zawierający jedno działanie podrzędne. Działanie jest bez CodeActivity kodu w przypadku WF3 i Comment działanie w przypadku WF4.

Z 1000 iteracjami

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 WF3 ma tryby wykonywania sekwencyjnego i równoległego. W trybie sekwencyjnym wydajność działania jest podobna WhileActivitydo wartości . Jest ReplicatorActivity to najbardziej przydatne w przypadku wykonywania równoległego. Analog WF4 dla tego jest ParallelForEach<T> działanie.

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ę nieco 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 partii 50 iteracji przez pętlę while jest liczone jako pojedyncza operacja.

Kompensata

Przepływ pracy WF3 ma jedno działanie wyrównywalne 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 następna w sekwencji. Działanie treści i działanie procedury obsługi kompensacji są zarówno puste implementacje:

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 platformy WF poprawiła się na całej tablicy, zwłaszcza w obszarach wymagających wielu wykonań tego samego działania, takiego 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 organizuje dwa wywołania usługi w celu zakupu zamówienia. 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/sekundy jest oparty na liczbie ukończonych PurchaseOrder wywołań wykonanych w usłudze sklepu online. Buforowanie kanałów to nowa funkcja dostępna w programie WF4. W części WCF tego buforowania kanałów testowych nie jest dostarczany z pudełka, więc ręcznie zakodowana implementacja prostej techniki buforowania została użyta w usłudze sklepu online.

Wydajność

Połączenie do usług TCP zaplecza bez buforowania kanałów, usługa WF ma 17,2% wpływ na przepływność. W przypadku buforowania 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 międzyoperacji, znacznie zmieniły się między WF3 i 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.

Konfigurowanie ś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 powiązania kontekstu i używa nagłówka kontekstu lub pliku cookie do powiązania komunikatów z poprawnym 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świetlane jest tylko jedno działanie komentarza. Liczba działań komentarzy została zmieniona w celu symulowania złożoności przepływu pracy. Działanie komentarza jest równoważne WF3 CodeActivity , które 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 tekstu

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 usuwania serializacji/kopiowania komunikatów. 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.

Konfigurowanie ś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 tekstu

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 zawartości zmienia się z środowiska uruchomieniowego przepływu pracy na bazę danych SQL. Procedury składowane u dostawcy trwałości SQL wykonują pracę zgodną z kluczami w celu zlokalizowania odpowiedniego przepływu pracy.

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 elementów podrzędnych, a te dzieci mogą być również działaniami złożonymi. W miarę zwiększania się liczby poziomów zagnieżdżania liczba działań, które mogą być obecnie w stanie wykonywania, oraz liczbę zmiennych, które mogą być w stanie. 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 działanie równoległe, a pętla, decyzje, przypisania i sekwencje. W projektancie WF4 na zdjęciu poniżej przedstawiono wykres blokowy najwyższego poziomu. Każde działanie schematu blokowego przypomina główny schemat blokowy. Warto pomyśleć o fraktalnie podczas pikowania tego przepływu pracy, 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 dolnym poziomie głębokości te schematy blokowe są puste, ale na innych poziomach są kopiami głównego schematu 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 na punkt decyzyjny jest wykonywana w danym wystąpieniu przepływu pracy, więc wykonywane są tylko małe podzbiór rzeczywistych działań.

Równoważny przepływ pracy został utworzony dla platformy WF3. Projektant WF3 pokazuje cały przepływ pracy w obszarze projektowania zamiast zagnieżdżania, dlatego wyświetlanie w tym temacie jest zbyt duże. 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 tekstu

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ść platformy WF4 jest o wiele większa 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: pojedynczy przepływ pracy działania i sekwencję z 1000 działaniami. 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 platformy WF3 są używane puste CodeActivity działania. 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 1000, złożona głębokość 5 5 i złożone zmiany głębokości 7 sekwencji 1, jasne jest, że wraz z wejściem liczby działań do tysięcy wzrost użycia pamięci staje się bardziej zauważalny. W skrajnym przypadku (głębokość 7 sekwencja 1), gdzie istnieją 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 w tym, że dany przepływ pracy jest wystąpiony 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 uruchomienie danego wystąpienia przepływu pracy powinna zostać wyczyszczona podczas odzyskiwania pamięci. 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 polecenia do utworzenia pojedynczego wystąpienia przepływu pracy lub bezpośredniego użycia 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ą parzystość funkcji, WorkflowRuntime która została użyta w tym teście.

W przypadku hostowania przepływów pracy w usługach IIS można użyć VirtualPathProvider elementu , 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. Pojedyncze działanie było puste CodeActivity dla przypadku WF3 i Comment działanie dla przypadku WF4. Przypadek hostowany przez usługi IIS używał przepływów pracy, które zaczynają odbierać komunikat i kończą wysyłanie 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	Delta zestawu roboczego WF4
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 usługach IIS zużywa znacznie więcej pamięci ze względu na WorkflowServiceHost, szczegółowe artefakty usługi WCF i logikę przetwarzania komunikatów skojarzona 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 WorkflowServiceHost hostowanych przez usługi IIS obiekt utworzony dla definicji przepływu pracy pozostaje w pamięci, dopóki pula aplikacji nie zostanie odzyskana. 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

Trwałość

Zarówno WF3, jak i WF4 są dostarczane z dostawcą trwałości 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 wykonać deserializacji każdego utrwalonego wystąpienia i zbadać zawartość. Wielu deweloperów woli pisać własnych dostawców 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 promotable. Nowa funkcja korelacji oparta na zawartości w programie WF4 nie działa dobrze przy użyciu podejścia do trwałości SQL WF3, co spowodowało pewne zmiany w organizacji 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.

Konfigurowanie ś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 jest utrwalany. W przypadku platformy WF3 pusta TransactionScopeActivity jest używana do inicjowania trwałości. To samo można osiągnąć w programie WF3, oznaczając działanie jako "utrwalone przy zamknięciu". Drugi skorelowany komunikat kończy przepływ pracy. Przepływy pracy są utrwalane, ale nie są zwalniane.

Wyniki tekstu

Gdy transport między klientem a warstwą środkową to HTTP, trwałość w programie WF4 pokazuje poprawę 2,6 razy. Transport TCP zwiększa ten współczynnik do 3,0 razy. We wszystkich przypadkach użycie procesora CPU w warstwie środkowej wynosi 98% lub więcej. Powodem zwiększenia przepływności WF4 jest szybsze środowisko uruchomieniowe przepływu pracy. Rozmiar serializowanego wystąpienia jest niski w obu przypadkach i nie jest głównym elementem przyczyniającym się 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 korzyść z utrwalania przepływu pracy bez zwalniania go. W programie WF3 można również utrwalać przy użyciu TimeToUnload tej funkcji, ale zwalnia to wystąpienie przepływu pracy z pamięci. Jeśli deweloper korzystający z platformy WF3 chce upewnić się, że przepływ pracy będzie się powtarzać w określonych punktach, musi zmienić definicję przepływu pracy lub zapłacić koszt zwolnienia i ponownego załadowania wystąpienia przepływu pracy. Nowa funkcja w programie WF4 umożliwia utrwalanie bez zwalniania: TimeToPersist. Ta funkcja umożliwia utrwalanie wystąpienia przepływu pracy w stanie bezczynności, ale pozostanie 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:

• Dysk fizyczny\%Czas odczytu dysku

• Dysk fizyczny\% czas dysku

• Dysk fizyczny\% czas zapisu dysku

• Dysk fizyczny\% średnia długość kolejki dysku

• PhysicalDisk\Avg. Długość kolejki odczytu dysku

• PhysicalDisk\Avg. Długość kolejki zapisu dysku

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

• Informacje o procesorze\% czasu procesora

• SQLServer:Latches\Average Latch Wait Time (ms)

• SQLServer:Latches\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. Bardziej złożony profil śledzenia, droższe śledzenie staje się.

WF3 dostarczany z usługą śledzenia opartą na języku SQL. Ta usługa może działać w trybach wsadowych i niesadowanych. W trybie niesadowym zdarzenia śledzenia są zapisywane bezpośrednio w bazie danych. W trybie wsadowym zdarzenia śledzenia są zbierane w tej samej partii co stan wystąpienia 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. Dostawca śledzenia out-of-the-box 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ą bardziej wydajne niż liczniki wydajności w tym zdarzeń można 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 bitów, dzięki czemu korzystanie z 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 programu WCF lub innymi dostawcami ETW, takimi jak program 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 recyklingu procesu hosta.

Zalety wydajności śledzenia ETW mają wadę. Zdarzenia ETW można utracić, jeśli system jest pod intensywnym ciśnieniem 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 funkcja ETW jest doskonałym rozwiązaniem do monitorowania kondycji, ale nie nadaje się do przeprowadzania inspekcji.

Chociaż WF4 nie ma dostawcy śledzenia SQL, program AppFabric robi. Podejście do śledzenia SQL programu AppFabric polega na subskrybowaniu zdarzeń ETW za pomocą usługi systemu Windows, która wsaduje zdarzenia i zapisuje je w tabeli SQL przeznaczonej do szybkiego wstawiania. Oddzielne zadanie opróżnia dane z tej tabeli i reformuje je w tabelach raportowania, które można wyświetlić na pulpicie nawigacyjnym appFabric. Oznacza to, że partia zdarzeń śledzenia jest obsługiwana 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 korzystania ze 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 narzędziu AppFabric, jest pokazany w tym tezie porównawczym. Uwzględniana jest również koszt śledzenia tylko zdarzeń monitorowania kondycji. Te zdarzenia są przydatne do rozwiązywania problemów i określania średniej przepływności systemu.

Konfigurowanie środowiska

Wyniki tekstu

Monitorowanie kondycji ma mniej więcej 3% wpływ na przepływność. Koszt profilu podstawowego wynosi około 8%.

Interop

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 platformy WF4 jest użycie działania Międzyoperajności, które może wykonywać działania WF3 z poziomu przepływu pracy WF4. Zaleca się, aby Interop działanie było używane tylko w razie potrzeby. Aby uzyskać więcej informacji na temat migracji do platformy WF4, zapoznaj się ze wskazówkami dotyczącymi migracji WF4.

Konfigurowanie środowiska

Wyniki tekstu

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

Przetestuj	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

Istnieje godny uwagi wzrost wydajności w celu korzystania z międzyoperajności na prostej 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. Oznacza to, że kara za korzystanie z platformy WF w przeciwieństwie do usług orkiestracji WCF kodowania ręcznego 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.