Windows Workflow Foundation 4 Performansı

.NET Framework 4, performansa yönelik yoğun yatırımlarla Windows Workflow Foundation'ın (WF) önemli bir düzeltmesini içerir. Bu yeni düzeltme, .NET Framework 3.0 ve .NET Framework 3.5'in bir parçası olarak gönderilen WF'nin önceki sürümlerinden önemli tasarım değişiklikleri sağlar. Performansı ve kullanılabilirliği büyük ölçüde geliştirmek için programlama modelinin, çalışma zamanının ve araçlarının çekirdeğinden yeniden tasarlanmıştır. Bu konu başlığında, bu düzeltmelerin önemli performans özellikleri gösterilir ve bunları önceki sürümle karşılaştırır.

Bireysel iş akışı bileşeni performansı, WF3 ile WF4 arasında kat kat artmıştır. Bu, el ile kodlanmış Windows Communication Foundation (WCF) hizmetleri ile WCF iş akışı hizmetleri arasındaki boşluğu oldukça küçük bırakır. WF4'te iş akışı gecikme süresi önemli ölçüde azaltıldı. Kalıcılık performansı 2,5 - 3,0 kat arttı. İş akışı izleme yoluyla sağlık izlemenin ek yükü önemli ölçüde daha azdır. Bunlar, uygulamalarınızda WF4'e geçiş yapmak veya bunları benimsemek için cazip nedenlerdir.

Terminoloji

.NET Framework 4'te kullanıma sunulan WF sürümü, bu konunun geri kalanı için WF4 olarak adlandırılır. WF, .NET Framework 3.0'da kullanıma sunulmuştur ve .NET Framework 3.5 SP1 aracılığıyla birkaç küçük düzeltme yapmıştır. Workflow Foundation'ın .NET Framework 3.5 sürümü, bu konunun geri kalanında WF3 olarak adlandırılır. WF3, .NET Framework 4'te WF4 ile yan yana gönderilir. WF3 yapıtlarını WF4'e geçirme hakkında daha fazla bilgi için bkz. Windows Workflow Foundation 4 Geçiş Kılavuzu.

Windows Communication Foundation (WCF), Microsoft'un hizmet odaklı uygulamalar oluşturmaya yönelik birleşik programlama modelidir. İlk olarak WF3 ile birlikte .NET Framework 3.0'ın bir parçası olarak kullanıma sunulmuştur ve şimdi .NET Framework'ün temel bileşenlerinden biridir.

Windows Server AppFabric, IIS üzerinde çalışan Web ve bileşik uygulamaları oluşturmayı, ölçeklendirmeyi ve yönetmeyi kolaylaştıran bir dizi tümleşik teknolojidir. Hizmetleri ve iş akışlarını izlemeye ve yönetmeye yönelik araçlar sağlar. Daha fazla bilgi için bkz. Windows Server AppFabric 1.0.

Hedefler

Bu konunun amacı, farklı senaryolar için ölçülen verilerle WF4'ün performans özelliklerini göstermektir. Ayrıca WF4 ile WF3 arasında ayrıntılı karşılaştırmalar sağlar ve bu nedenle bu yeni düzeltmede yapılan büyük iyileştirmeleri gösterir. Bu makalede sunulan senaryolar ve veriler, WF4 ve WF3'ün farklı yönlerinin temel maliyetini ölçmektedir. Bu veriler WF4'ün performans özelliklerini anlamak için kullanışlıdır ve WF3'ten WF4'e geçişleri planlamada veya uygulama geliştirmede WF4'ün kullanılmasında yararlı olabilir. Ancak, bu makalede sunulan verilerden elde edilecek sonuçlarda dikkatli olunmalıdır. Bileşik iş akışı uygulamasının performansı, iş akışının nasıl uygulandığına ve farklı bileşenlerin nasıl tümleştirildiğinden büyük ölçüde bağlıdır. Bir uygulamanın performans özelliklerini belirlemek için her uygulamayı ölçmesi gerekir.

WF4 Performans Geliştirmelerine Genel Bakış

WF4, aşağıdaki bölümlerde açıklanan yüksek performans ve ölçeklenebilirlikle dikkatlice tasarlanıp uygulandı.

WF Çalışma Zamanı

WF çalışma zamanının çekirdeğinde, bir iş akışındaki etkinliklerin yürütülmesini yönlendiren zaman uyumsuz bir zamanlayıcı bulunur. Etkinlikler için performanslı, öngörülebilir bir yürütme ortamı sağlar. Ortamın yürütme, devamlılık, tamamlama, iptal, özel durumlar ve öngörülebilir bir iş parçacığı modeli için iyi tanımlanmış bir sözleşmesi vardır.

WF3'e kıyasla WF4 çalışma zamanı daha verimli bir zamanlayıcıya sahiptir. Aynı WCF için kullanılan G/Ç iş parçacığı havuzundan yararlanarak toplu iş öğelerini yürütmede çok verimlidir. İç iş öğesi zamanlayıcı kuyruğu en yaygın kullanım düzenleri için iyileştirilmiştir. WF4 çalışma zamanı, yürütme durumlarını çok az eşitleme ve olay işleme mantığıyla çok basit bir şekilde yönetirken, WF3 ise durum geçişleri için karmaşık eşitleme gerçekleştirmek için ağır olay kaydına ve çağırmaya bağlıdır.

Veri Depolama ve Akış

WF3'te, bir etkinlikle ilişkili veriler türü DependencyPropertytarafından uygulanan bağımlılık özellikleri aracılığıyla modellenmiştir. Bağımlılık özelliği deseni Windows Presentation Foundation'da (WPF) tanıtıldı. Genel olarak, bu desen kolay veri bağlamayı ve diğer kullanıcı arabirimi özelliklerini desteklemek için çok esnektir. Ancak, desen, özelliklerin iş akışı tanımında statik alanlar olarak tanımlanmasını gerektirir. WF çalışma zamanı özellik değerlerini her ayarladığında veya aldığında, yüksek derecede karmaşık bir arama mantığını içerir.

WF4, verilerin iş akışında nasıl işleneceğini büyük ölçüde geliştirmek için net veri kapsam belirleme mantığını kullanır. Bir etkinlikte depolanan verileri, etkinliğin sınırları boyunca akan verilerden ayırmak için iki farklı kavram kullanır: değişkenler ve parametreler. Değişkenler ve "In/Out/InOut" bağımsız değişkenleri için net bir hiyerarşik yapı kullanıldığında, aktiviteler için veri kullanımının karmaşıklığı önemli ölçüde azalır ve verilerin kullanım ömrü de otomatik olarak belirlenir. Etkinliklerin, bağımsız değişkenleriyle tanımlanan belirgin bir imzası vardır. Bir etkinliği inceleyerek, hangi verileri almayı beklediğini ve yürütmesinin sonucu olarak hangi verilerin üretileceğini belirleyebilirsiniz.

WF3'te bir iş akışı oluşturulduğunda etkinlikler başlatıldı. WF 4'te etkinlikler yalnızca ilgili etkinlikler yürütülürken başlatılır. Bu, yeni bir iş akışı örneği oluşturulduğunda Initialize/Uninitialize işlemleri gerçekleştirmeden daha basit bir etkinlik yaşam döngüsü sağlar ve böylece daha fazla verimlilik elde eder

Denetim Akışı

Her programlama dilinde olduğu gibi WF de sıralama, döngü, dallanma ve diğer desenler için bir dizi denetim akışı etkinliği sunarak iş akışı tanımları için denetim akışları için destek sağlar. WF3'te, aynı etkinliğin yeniden yürütülmesi gerektiğinde yeni ActivityExecutionContext oluşturulur ve etkinliğin kopyası, BinaryFormatter temel alınarak ağır bir serileştirme ve seri durumdan çıkarma mantığı aracılığıyla oluşturulur. Yinelemeli denetim akışlarının performansı genellikle bir etkinlik dizisi yürütmeye kıyasla çok daha yavaştır.

WF4 bunu oldukça farklı bir şekilde ele alır. Etkinlik şablonunu alır, yeni bir ActivityInstance nesnesi oluşturur ve zamanlayıcı kuyruğuna ekler. Bu işlemin tamamı yalnızca açık nesne oluşturmayı içerir ve çok basit bir işlemdir.

Zaman Uyumsuz Programlama

Uygulamalar, uzun süren engelleyici işlemler, örneğin G/Ç veya dağıtılmış bilgi işlem işlemleri için asenkron programlama ile genellikle daha iyi performans ve ölçeklenebilirlik gösterir. WF4, temel etkinlik türleri AsyncCodeActivity, AsyncCodeActivity<TResult> aracılığıyla zaman uyumsuz destek sağlar. Çalışma zamanı, zaman uyumsuz işlemleri yerel olarak anladığından, zaman uyumsuz çalışma devam ederken örneği otomatik olarak kalıcı bir bölge dışında bir yere yerleştirebilir. Özel etkinlikler, iş akışı zamanlayıcısını meşgul etmeden ve paralel olarak çalışabilecek etkinlikleri engellemeden zaman uyumsuz iş gerçekleştirmek için bu türlerden türetilebilir.

Mesajlaşma

WF3 başlangıçta dış olaylar veya web hizmetleri çağrıları aracılığıyla çok sınırlı mesajlaşma desteğine sahipti. .NET Framework 3.5'te iş akışları, WCF istemcileri olarak uygulanabilir veya SendActivity ve ReceiveActivity aracılığıyla WCF hizmetleri olarak sunulabilir. WF4'te, WCF mesajlaşma mantığının WF ile sıkı tümleştirilmesiyle iş akışı tabanlı mesajlaşma programlama kavramı daha da güçlendirilmiştir.

.NET 4'te WCF'de sağlanan birleşik ileti işleme işlem hattı, WF4 hizmetlerinin WF3'ten önemli ölçüde daha iyi performans ve ölçeklenebilirlik elde etmelerine yardımcı olur. WF4 ayrıca karmaşık İleti Değişimi Desenlerini (MEP' ler) modelleyebilecek daha zengin mesajlaşma programlama desteği sağlar. Geliştiriciler, kolay programlama için türü belirlenmiş hizmet sözleşmelerini veya serileştirme maliyeti ödemeden daha iyi performans için türü belirlenmemiş hizmet sözleşmelerini kullanabilir. WF4'teki SendMessageChannelCache sınıfı aracılığıyla istemci tarafı kanal önbelleğe alma desteği, geliştiricilerin hızlı uygulamalar oluşturmalarına en az çabayla yardımcı olur. Daha fazla bilgi için bkz. Gönderme Etkinlikleri için Önbellek Paylaşım Düzeylerini Değiştirme.

Bildirim temelli Programlama

WF4, iş süreçlerini ve hizmetlerini modellemek için temiz ve basit bildirim temelli bir programlama çerçevesi sağlar. Programlama modeli, kod eşliği gerektirmeyen tamamen bildirim temelli etkinlik bileşimini destekler, bu da iş akışları oluşturmayı büyük ölçüde basitleştirir. .NET Framework 4'te, XAML tabanlı bildirim temelli programlama çerçevesi, hem WPF hem WF'yi desteklemek amacıyla System.Xaml.dll içinde tek bir bütün olarak birleştirildi.

WF4'te XAML, gerçek anlamda bildirim temelli bir deneyim sağlar ve iş akışının tüm tanımının XML işaretlemesinde tanımlanmasına, .NET kullanılarak oluşturulan etkinliklere ve türlere başvurmasına olanak tanır. XOML formatında, özel kod mantığı kullanmadan WF3'te bunu yapmak zordu. .NET 4'teki yeni XAML yığını, iş akışı yapıtlarını seri hale getirme/seri durumdan çıkarma konusunda çok daha iyi performansa sahiptir ve bildirim temelli programlamayı daha çekici ve sağlam hale getirir.

İş Akışı Tasarımcısı

WF4 için tam bildirim temelli programlama desteği, büyük iş akışları için tasarım süresi performansı için açıkça daha yüksek gereksinimler uygular. WF4'teki İş Akışı tasarımcısı, büyük iş akışları için WF3'ten çok daha iyi ölçeklenebilirliğe sahiptir. Kullanıcı arabirimi sanallaştırma desteği sayesinde tasarımcı birkaç saniye içinde 1000 etkinlik içeren büyük bir iş akışını kolayca yükleyebilirken, WF3 tasarımcısına birkaç yüz etkinliklik bir iş akışı yüklemek neredeyse imkansızdır.

Bileşen Düzeyinde Performans Karşılaştırmaları

Bu bölüm, WF3 ve WF4 iş akışlarındaki tek tek etkinlikler arasındaki doğrudan karşılaştırmalara ilişkin verileri içerir. Kalıcılık gibi önemli alanların performans üzerinde tek tek etkinlik bileşenlerine göre daha derin bir etkisi vardır. WF4'teki tek tek bileşenlerdeki performans geliştirmeleri önemlidir, çünkü bileşenler artık el ile kodlanmış düzenleme mantığıyla karşılaştırılacak kadar hızlıdır. Bir örnek sonraki bölümde ele alınmıştır: "Hizmet Oluşturma Senaryosu."

Ortam Kurulumu

Yukarıdaki şekilde, bileşen düzeyinde performans ölçümü için kullanılan makine yapılandırması gösterilmektedir. Tek bir sunucu ve 1 Gb/sn Ethernet ağ arabirimi üzerinden bağlanan beş istemci. Kolay ölçümler için sunucu, Windows Server 2008 x86 çalıştıran bir çift proc/dört çekirdekli sunucunun tek çekirdeğini kullanacak şekilde yapılandırılır. Sistem CPU kullanımı neredeyse 100%seviyesinde tutulmaktadır.

Test Ayrıntıları

WF3 CodeActivity büyük olasılıkla bir WF3 iş akışında kullanılabilecek en basit etkinliktir. Etkinlik, iş akışı programcısının özel kod yerleştirebileceği arka planda bir yöntem çağırır. WF4'te, aynı işlevselliği sağlayan WF3'e CodeActivity doğrudan analog yoktur. WF4'te WF3 CodeActivityile ilgili olmayan bir CodeActivity temel sınıf olduğunu unutmayın. İş akışı yazarlarının özel etkinlikler oluşturması ve yalnızca XAML iş akışları oluşturması teşvik edilir. Aşağıdaki testlerde, WF4 iş akışlarında boş Comment bir etkinlik yerine adlı CodeActivity bir etkinlik kullanılır. Etkinlikteki Comment kod aşağıdaki gibidir:

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

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

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Boş İş Akışı

Bu test, alt etkinlik içermeyen bir sıralı iş akışı kullanır.

Tek Etkinlik

İş akışı, tek bir alt etkinliği içeren sıralı bir iş akışıdır. Etkinlik, WF3 durumunda kod içermeyen bir CodeActivity ve WF4 durumundaki bir Comment etkinliktir.

1000 Yineleme ile

Sıralı iş akışı, döngüde herhangi bir While iş gerçekleştirmeyen bir alt etkinlik içeren bir etkinlik içerir.

ParallelForEach ile karşılaştırıldığında çoğaltıcı

ReplicatorActivity WF3'te sıralı ve paralel yürütme modları vardır. Sıralı modda, etkinliğin performansı, WhileActivity ile benzerdir. ReplicatorActivity paralel yürütme için en kullanışlı olandır. WF4 için bu analog ParallelForEach<T> etkinliğidir.

Aşağıdaki diyagramda bu test için kullanılan iş akışları gösterilmektedir. WF3 iş akışı solda, WF4 iş akışı ise sağdadır.

Beş Etkinlikli Sıralı İş Akışı

Bu test, birkaç etkinliğin sırayla yürütülmesinin etkisini göstermek için tasarlanır. Dizide beş etkinlik vardır.

İşlem Kapsamı

İşlem kapsamı testi, her yineleme için yeni bir iş akışı örneği oluşturulmadığı için diğer testlerden biraz farklıdır. Bunun yerine, iş akışı, herhangi bir görev yapmayan tek bir etkinliği içeren TransactionScope etkinliği ile yapılandırılmış bir while döngüsüne sahiptir. while döngüsü aracılığıyla 50 yinelemeden oluşan bir toplu işin her çalıştırması tek bir işlem olarak sayılır.

Ücret

WF3 adlı iş akışının, WorkScope adlı tek bir telafi edilebilir etkinliği vardır. Etkinlik yalnızca ICompensatableActivity arabirimini uygular.

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

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

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

Hata işleyicisi WorkScope etkinliğini hedefler. WF4 iş akışı da eşit derecede basittir. CompensableActivity bir gövdeye ve bir telafi işleyicisine sahiptir. Sırada açıkça tanımlanmış bir telafi vardır. Gövde etkinliği ve telafi işleyicisi etkinliği boş uygulamalardır:

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

Aşağıdaki diyagramda temel ücret iş akışı gösterilmektedir. WF3 iş akışı solda, WF4 iş akışı ise sağdadır.

Performans Testi Sonuçları

Tüm testler, işlem kapsamı testi dışında saniye başına iş akışlarında ölçülür. Yukarıda da görülebileceği gibi, özellikle while döngüsü gibi aynı etkinliğin birden çok yürütülmesini gerektiren alanlarda WF çalışma zamanı performansı pano genelinde geliştirilmiştir.

Hizmet Oluşturma Senaryosu

Önceki "Bileşen Düzeyi Performans Karşılaştırmaları" bölümünde gösterildiği gibi, WF3 ile WF4 arasındaki ek yükte önemli bir azalma olmuştur. WCF iş akışı hizmetleri artık el ile kodlanmış WCF hizmetlerinin performansıyla neredeyse eşleşebilir ancak WF çalışma zamanının tüm avantajlarına sahip olmaya devam edebilir. Bu test senaryosu bir WCF hizmetini WF4'teki bir WCF iş akışı hizmetiyle karşılaştırır.

Çevrimiçi Mağaza Hizmeti

Windows Workflow Foundation'ın güçlü yönlerinden biri, çeşitli hizmetleri kullanarak işlemler oluşturabilmektir. Bu örnekte, sipariş satın almak için iki hizmet çağrısını düzenleyen bir çevrimiçi mağaza hizmeti vardır. İlk adım, Sipariş Doğrulama Hizmeti kullanarak siparişi doğrulamaktır. İkinci adım, ambar hizmeti kullanarak siparişi doldurmaktır.

İki arka uç hizmeti olan Sipariş Doğrulama Hizmeti ve Ambar Hizmeti her iki test için de aynı kalır. Değişen bölüm, düzenlemeyi gerçekleştiren Çevrimiçi Mağaza Hizmeti'dir. Bir durumda hizmet, WCF hizmeti olarak el ile kodlanır. Diğer durumda, hizmet WF4'te wcf iş akışı hizmeti olarak yazılır. İzleme ve kalıcılık gibi WF'ye özgü özellikler bu test için kapatılır.

Çevre

İstemci istekleri, birden çok bilgisayardan HTTP aracılığıyla Çevrimiçi Mağaza Hizmeti'ne yapılır. Tek bir bilgisayar üç hizmeti de barındırıyor. Çevrimiçi Mağaza Hizmeti ile arka uç hizmetleri arasındaki aktarım katmanı TCP veya HTTP'dir. İşlemlerin/saniyenin ölçümü, Çevrimiçi Mağaza Hizmeti'ne yapılan tamamlanmış PurchaseOrder çağrıların sayısına bağlıdır. Kanal havuzu, WF4'te kullanılabilen yeni bir özelliktir. Test kanalının WCF bölümünde havuzlama varsayılan olarak sunulmadığından, Çevrimiçi Mağaza Hizmeti'nde basit bir havuzlama tekniğinin elle kodlanmış bir uygulaması kullanılmıştır.

Gösteri

Kanal havuzu olmadan arka uç TCP hizmetlerine bağlanan WF hizmetinin aktarım hızı üzerinde 17,2% etkisi vardır. Kanal birleştirme ile ceza yaklaşık 23,8%. HTTP için etki çok daha azdır: havuzlama yapılmadan 4,3% ve havuzlama ile 8,1%. Ayrıca, HTTP kullanırken kanal havuzunun çok az avantaj sağladığını da unutmayın.

Bu testte el ile kodlanmış bir WCF hizmeti ile karşılaştırıldığında, WF4 çalışma zamanı yük bindirmesi olsa da en kötü durum senaryosu olarak kabul edilebilir. Bu testteki iki arka uç hizmeti çok az iş yapıyor. Gerçek bir uçtan uca senaryoda, bu hizmetler veritabanı çağrıları gibi daha pahalı işlemler gerçekleştirerek aktarım katmanının performans etkisini daha az önemli hale getirir. Bunun yanı sıra WF4'teki özelliklerin avantajları, Workflow Foundation'ın düzenleme hizmetleri oluşturmak için uygun bir seçim olmasını sağlar.

Önemli Performans Konuları

Interop dışındaki bu bölümdeki özellik alanları, WF3 ile WF4 arasında önemli ölçüde değişmiştir. Bu, iş akışı uygulamalarının tasarımını ve performansı etkiler.

İş Akışı Etkinleştirme GecikmeSi

WCF iş akışı hizmeti uygulamasında, yeni bir iş akışı başlatma veya var olan bir iş akışını yükleme gecikme süresi engelleyici olabileceğinden önemlidir. Bu test çalışması, tipik bir senaryoda WF3 XOML konağı ile WF4 XAMLX konağı karşılaştırarak ölçer.

Ortam Kurulumu

Test Kurulumu

Senaryoda, istemci bilgisayar bağlam tabanlı bağıntı kullanarak bir WCF iş akışı hizmetiyle iletişim kurar. Bağlam ilişkilendirmesi özel bir bağlam bağlaması gerektirir ve iletileri doğru iş akışı örneğiyle ilişkilendirmek için bir bağlam üst bilgisi veya tanımlama bilgisi kullanır. bağıntı kimliğinin ileti üst bilgisinde bulunması nedeniyle ileti gövdesinin ayrıştırılması gerekmez.

Hizmet, istekle yeni bir iş akışı oluşturur ve iş akışını çalıştırmaya harcanan sürenin gecikme süresi ölçümüne dahil edilmemesi için hemen bir yanıt gönderir. WF3 iş akışı arka planda kod içeren XOML, WF4 iş akışı ise tamamen XAML'dir. WF4 iş akışı şöyle görünür:

Etkinlik, Receive iş akışı örneğini oluşturur. Alınan iletide geçirilen bir değer yanıt iletisinde yankılanır. Yanıtı izleyen bir dizi, iş akışının geri kalanını içerir. Yukarıdaki durumda, yalnızca bir açıklama etkinliği gösterilir. açıklama etkinliklerinin sayısı, iş akışı karmaşıklığını simüle etmek için değiştirilir. Açıklama etkinliği, hiçbir iş yapmayan bir WF3 CodeActivity ile eşdeğerdir. Açıklama etkinliği hakkında daha fazla bilgi için bu makalenin önceki bölümlerinde yer alan "Bileşen düzeyi Performans Karşılaştırması" bölümüne bakın.

Test Sonuçları

WCF iş akışı hizmetleri için soğuk ve sıcak gecikme süresi:

Önceki grafikte soğuk, belirli bir iş akışı için mevcut WorkflowServiceHost olmayan durumu ifade eder. Başka bir deyişle, soğuk gecikme, iş akışının ilk kez kullanıldığı ve XOML veya XAML'nin derlenmesi gerektiği zamandır. Sıcak gecikme süresi, iş akışı türü zaten derlenmiş durumdayken yeni bir iş akışı örneği oluşturma zamanıdır. İş akışının karmaşıklığı WF4 durumunda çok az fark yaratır, ancak WF3 durumunda doğrusal bir ilerlemeye sahiptir.

Bağıntı Aktarım Hızı

WF4, yeni bir içerik tabanlı bağıntı özelliği tanıtır. WF3 yalnızca bağlam tabanlı bağıntı sağladı. Bağlam tabanlı bağıntı yalnızca belirli WCF kanalı bağlamaları üzerinden yapılabilir. İş akışı kimliği, bu bağlamalar kullanılırken ileti üst bilgisine eklenir. WF3 çalışma zamanı bir iş akışını yalnızca kimliğine göre tanımlayabilir. İçerik tabanlı bağıntı ile iş akışı yazarı, hesap numarası veya müşteri kimliği gibi ilgili bir veri parçasından bir bağıntı anahtarı oluşturabilir.

Bağlam tabanlı bağıntı, bağıntı anahtarının ileti üst bilgisinde bulunması açısından bir performans avantajına sahiptir. Mesajı serileştirmeden/iletiyi kopyalamadan anahtar okunabilir. İçerik tabanlı bağıntıda, bağıntı anahtarı ileti gövdesinde depolanır. Anahtarı bulmak için bir XPath ifadesi kullanılır. Bu ek işlemenin maliyeti iletinin boyutuna, gövdedeki anahtarın derinliğine ve anahtar sayısına bağlıdır. Bu test, bağlam ve içerik tabanlı bağıntıyı karşılaştırır ve ayrıca birden çok anahtar kullanılırken performans düşüşü gösterir.

Ortam Kurulumu

Test Kurulumu

Önceki iş akışı , Kalıcılık bölümünde kullanılan iş akışıyla aynıdır. Kalıcılığı olmayan bağıntı testleri için çalışma zamanında yüklü kalıcılık sağlayıcısı yoktur. Bağıntı iki yerde oluşur: CreateOrder ve CompleteOrder.

Test Sonuçları

Bu grafik, içerik tabanlı bağıntıda kullanılan anahtar sayısı arttıkça performans düşüşü gösterir. TCP ve HTTP arasındaki eğrilerdeki benzerlik, bu protokollerle ilişkili ek yükü gösterir.

Kalıcılık ile bağıntı

Kalıcı bir iş akışıyla, içerik tabanlı bağıntıdan gelen CPU baskısı iş akışı çalışma zamanından SQL veritabanına geçer. SQL kalıcılık sağlayıcısındaki saklı yordamlar, uygun iş akışını bulmak için anahtarları eşleştirme işini yapar.

Bağlam tabanlı bağıntı, içerik tabanlı bağıntıdan daha hızlıdır. Ancak kalıcılık bağıntıdan daha çok performans üzerinde etki gösterdiğinden fark daha az belirgindir.

Karmaşık İş Akışı Aktarım Hızı

Bir iş akışının karmaşıklığı yalnızca etkinlik sayısıyla ölçülür. Bileşik etkinlikler çok sayıda alt öğe içerebilir ve bu çocuklar da bileşik etkinlikler olabilir. İç içe yerleştirme düzeylerinin sayısı arttıkça, şu anda yürütme durumunda olabilecek etkinliklerin sayısı ve durumda olabilecek değişkenlerin sayısı da artar. Bu test, karmaşık iş akışlarını yürütürken WF3 ile WF4 arasındaki aktarım hızını karşılaştırır.

Test Kurulumu

Bu testler, Windows Server 2008 x64 çalıştıran 4 GB RAM'e sahip 2,66 GHz 4 yönlü bir Intel Xeon X5355 bilgisayarda yürütüldü. Test kodu, 100% CPU kullanımına ulaşmak için çekirdek başına bir iş parçacığıyla tek bir işlemde çalışır.

Bu test için oluşturulan iş akışlarının iki ana değişkeni vardır: derinlik ve her dizideki etkinlik sayısı. Her derinlik düzeyi paralel bir etkinlik, döngü, kararlar, atamalar ve diziler içerir. Aşağıda resmedilen WF4 tasarımcısında en üst düzey akış grafiği resmedilir. Her akış çizelgesi etkinliği ana akış çizelgesine benzer. Derinliğin testin parametreleriyle sınırlı olduğu bu iş akışını hayal ederken bir fraktal düşünmek yararlı olabilir.

Belirli bir testteki etkinliklerin sayısı, sıra başına etkinliklerin derinliğine ve sayısına göre belirlenir. Aşağıdaki denklem, WF4 testindeki etkinliklerin sayısını hesaplar:

WF3 testinin etkinlik sayısı, fazladan bir dizi nedeniyle biraz farklı bir denklemle hesaplanabilir:

Burada d derinlik, a ise sıra başına etkinlik sayısıdır. Bu denklemlerin arkasındaki mantık, ile çarpılan ilk sabitin dizi sayısı, ikinci sabitin ise geçerli düzeydeki statik etkinlik sayısı olmasıdır. Her bir akış şemasında üç akış şeması alt etkinliği vardır. Alt derinlik düzeyinde, bu akış çizelgeleri boş ancak diğer düzeylerde ana akış çizelgesinin kopyalarıdır. Her test varyasyonunun iş akışı tanımındaki etkinliklerin sayısı aşağıdaki tabloda belirtilmiştir:

İş akışı tanımındaki etkinliklerin sayısı her derinlik düzeyinde keskin bir şekilde artar. Ancak belirli bir iş akışı örneğinde karar noktası başına yalnızca bir yol yürütülür, bu nedenle gerçek etkinliklerin yalnızca küçük bir alt kümesi yürütülür.

WF3 için eşdeğer bir iş akışı oluşturuldu. WF3 tasarımcısı, iş akışının tamamını iç içe yerleştirmeden tasarım alanında gösterdiği için bu belgeye sığmayacak kadar büyük. aşağıda iş akışının bir kod parçacığı gösterilmektedir.

Aşırı bir durumda iç içe yerleştirme alıştırması yapmak için, bu testin parçası olan başka bir iş akışı 100 iç içe dizi kullanır. En içteki dizide tek Comment veya CodeActivityolur.

İzleme ve kalıcılık bu testin bir parçası olarak kullanılmaz.

Test Sonuçları

Çok fazla derinliğe ve çok sayıda etkinliğe sahip karmaşık iş akışlarında bile, performans sonuçları bu makalenin önceki bölümlerinde gösterilen diğer aktarım hızı sayılarıyla tutarlıdır. WF4'ün verimi, kat kat daha hızlıdır ve logaritmik ölçekte karşılaştırılması gerekir.

Hafıza

Windows Workflow Foundation'ın bellek yükü iki temel alanda ölçülür: iş akışı karmaşıklığı ve iş akışı tanımlarının sayısı. Windows 7 64 bit iş istasyonunda bellek ölçümleri alınmıştır. Performans sayaçlarını izleme, Environment.WorkingSet'i yoklama veya VMMap'ten edinilebilen VMMap gibi bir araç kullanma gibi çalışma kümesi boyutunu ölçmenin birçok yolu vardır. Her testin sonuçlarını almak ve doğrulamak için yöntemlerin bir bileşimi kullanılmıştır.

İş Akışı Karmaşıklık Testi

İş akışı karmaşıklık testi, iş akışının karmaşıklığı temelinde çalışma kümesi farkını ölçer. Önceki bölümde kullanılan karmaşık iş akışlarına ek olarak, iki temel durumu kapsayacak şekilde yeni çeşitlemeler eklenir: tek etkinlik iş akışı ve 1000 etkinlik içeren bir dizi. Bu testler için iş akışları başlatılır ve bir dakikalık bir süre boyunca tek bir seri döngüde tamamlanmak üzere yürütülür. Her test varyasyonu üç kez çalıştırılır ve kaydedilen veriler bu üç çalıştırmanın ortalamasıdır.

İki yeni temel test, aşağıda gösterilenlere benzer iş akışlarına sahiptir:

Yukarıda gösterilen WF3 iş akışında boş CodeActivity etkinlikler kullanılır. Yukarıdaki WF4 iş akışı Comment etkinliklerini kullanır. Etkinlik, Comment bu makalenin önceki bölümlerindeki Bileşen Düzeyinde Performans Karşılaştırmaları bölümünde açıklanmıştır.

Bu grafikte farkedilmesi gereken açık eğilimlerden biri, iç içe yerleştirmenin hem WF3 hem de WF4'te bellek kullanımı üzerinde nispeten en az etkiye sahip olmasıdır. Bellek üzerindeki en önemli etki, belirli bir iş akışındaki etkinlik sayısından kaynaklanmaktadır. Dizi 1000, karmaşık derinlik 5 sıra 5 ve karmaşık derinlik 7 sıra 1 çeşitlemelerindeki veriler göz önünde bulundurulduğunda, etkinlik sayısı binlere girdikçe bellek kullanımı artışının daha belirgin hale geldiği açıktır. Yaklaşık 29.000 etkinliğin bulunduğu aşırı durumda (derinlik 7 sıra 1), WF4 WF3'ten neredeyse 79% daha az bellek kullanıyor.

Birden Çok İş Akışı Tanımı Testi

WF3 ve WF4'te iş akışlarını barındırmaya yönelik kullanılabilir seçenekler nedeniyle iş akışı tanımı başına belleğin ölçülmesi iki farklı teste ayrılır. Testler, belirli bir iş akışının tanım başına yalnızca bir kez örneklenip yürütülmesindeki iş akışı karmaşıklık testinden farklı bir şekilde çalıştırılır. Bunun nedeni, iş akışı tanımının ve konağın AppDomain'in ömrü boyunca bellekte kalmasıdır. Belirli bir iş akışı örneği çalıştırılarak kullanılan bellek, çöp toplama sırasında temizlenmelidir. WF4 için geçiş kılavuzu, barındırma seçenekleri hakkında daha ayrıntılı bilgi içerir. Daha fazla bilgi için bkz. WF Migration Cookbook: Workflow Hosting.

bir iş akışı tanımı testi için birçok iş akışı tanımı oluşturma işlemi çeşitli yollarla yapılabilir. Örneğin, ad dışında aynı olan 1000 iş akışı kümesi oluşturmak ve bu iş akışlarının her birini ayrı dosyalara kaydetmek için kod oluşturmayı kullanabilirsiniz. Bu yaklaşım konsolda barındırılan test için uygulanmıştır. WF3'te, WorkflowRuntime iş akışı tanımlarını çalıştırmak için sınıfı kullanılmıştır. WF4, ya tek bir iş akışı örneği oluşturmak için WorkflowApplication kullanabilir ya da doğrudan WorkflowInvoker kullanarak etkinliği bir yöntem çağrısı gibi çalıştırabilir. WorkflowApplication tek bir iş akışı örneğinin konağıdır ve bu testte kullanılmak üzere WorkflowRuntime daha yakın özellik eşliğine sahiptir.

IIS'de iş akışları barındırılırken, tüm XAMLX veya XOML dosyalarını oluşturmak yerine, yeni bir VirtualPathProvider oluşturmak için WorkflowServiceHost kullanmak mümkündür. gelen VirtualPathProvider isteği işler ve bir veritabanından yüklenebilen veya bu durumda anında oluşturulan bir "sanal dosya" ile yanıt verir. Bu nedenle 1000 fiziksel dosya oluşturmak gereksizdir.

Konsol testinde kullanılan iş akışı tanımları tek bir etkinliğe sahip basit sıralı iş akışlarıydı. Tek etkinlik, WF3 durumu için bir CodeActivity boştu ve WF4 durumu için bir Comment etkinlikti. IIS tarafından barındırılan servis talebi, ileti almaya başlayıp yanıt göndermeyle biten iş akışlarını kullandı:

Aşağıdaki görüntüde ReceiveActivity içeren bir WF3 iş akışı ve istek/yanıt deseni olan bir WF4 iş akışı gösterilmektedir:

Aşağıdaki tabloda, tek bir iş akışı tanımı ile 1001 tanımları arasındaki çalışma kümesindeki delta gösterilmektedir:

Barındırma Seçenekleri	WF3 Çalışma Kümesi Deltası	WF4 Çalışma Kümesi Deltası
Konsol Uygulaması Barındırılan İş Akışları	18 MB	9 MB
IIS Barındırılan İş Akışı Hizmetleri	446 MB	364 MB

IIS'de iş akışı tanımlarını barındırmak, ayrıntılı WCF hizmet yapıtları ve konakla ilişkili ileti işleme mantığı nedeniyle WorkflowServiceHostçok daha fazla bellek tüketir.

WF3'te konsol barındırma için iş akışları XOML yerine kodda uygulandı. WF4'te varsayılan olarak XAML kullanılır. XAML, assembly'de gömülü bir kaynak olarak depolanır ve iş akışının uygulanmasını sağlamak için çalışma zamanında derlenir. Bu işlemle ilişkili bazı ek yük vardır. WF3 ile WF4 arasında adil bir karşılaştırma yapmak için XAML yerine kodlanmış iş akışları kullanıldı. WF4 iş akışlarından birinin örneği aşağıda gösterilmiştir:

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

Bellek tüketimini etkileyebilecek başka birçok faktör vardır. Tüm yönetilen programlar için aynı öneri yine de geçerlidir. IIS tarafından barındırılan WorkflowServiceHost ortamlarda, bir iş akışı tanımı için oluşturulan nesne, uygulama havuzu geri dönüştürülene kadar bellekte kalır. Uzantılar yazılırken bu göz önünde bulundurulmalıdır. Ayrıca, "genel" değişkenlerden (iş akışının tamamı kapsamındaki değişkenler) kaçınmak ve mümkün olan her yerde değişkenlerin kapsamını sınırlamak en iyisidir.

İş Akışı Çalışma Süresi Hizmetleri

Devamlılık

WF3 ve WF4'in her ikisi de bir SQL kalıcılık sağlayıcısıyla birlikte gelir. WF3 SQL kalıcılık sağlayıcısı, iş akışı örneğini seri hale getiren ve bir blobda depolayan basit bir uygulamadır. Bu nedenle, bu sağlayıcının performansı büyük ölçüde iş akışı örneğinin boyutuna bağlıdır. WF3'te, bu makalede daha önce açıklandığı gibi örnek boyutu birçok nedenden dolayı artabilir. Serileştirilmiş bir örneği veritabanında depolamak iş akışının durumuyla ilgili görünürlük sağlamadığından birçok müşteri varsayılan SQL kalıcılık sağlayıcısını kullanmamayı tercih eder. İş akışı kimliğini bilmeden belirli bir iş akışını bulmak için kalıcı olan her örneğin seri durumdan çıkarılması ve içeriğinin incelenmesi gerekir. Birçok geliştirici bu engeli aşmak için kendi kalıcılık sağlayıcılarını yazmayı tercih ediyor.

WF4 SQL kalıcılık sağlayıcısı bu sorunlardan bazılarını gidermeye çalıştı. Kalıcılık tabloları, etkin yer işaretleri ve tanıtılabilir özellikler gibi belirli bilgileri gösterir. WF4'teki yeni içerik tabanlı bağıntı özelliği, kalıcı iş akışı örneğinin kuruluşunda bazı değişikliklere yol açan WF3 SQL kalıcılığı yaklaşımını kullanarak iyi performans göstermeyebilir. Bu, kalıcılık sağlayıcısının işini daha karmaşık hale getirir ve veritabanında fazladan stres yaratır.

Ortam Kurulumu

Test Kurulumu

Geliştirilmiş özellik kümesi ve daha iyi eşzamanlılık işleme ile bile, WF4'teki SQL kalıcılık sağlayıcısı WF3'teki sağlayıcıdan daha hızlıdır. Bunu göstermek için WF3 ve WF4'te temelde aynı işlemleri gerçekleştiren iki iş akışı aşağıda karşılaştırılır.

İki iş akışı da alınan bir ileti tarafından oluşturulur. İlk yanıtı gönderdikten sonra iş akışı kalıcı hale gönderilir. WF3 durumunda, kalıcılığı başlatmak için bir boş TransactionScopeActivity kullanılır. Aynı şey WF3'te de bir etkinliği "kapanışta kalıcı" olarak işaretleyerek elde edilebilir. İkinci bir bağıntılı ileti iş akışını tamamlar. İş akışları kalıcıdır ancak kaldırılmaz.

Test Sonuçları

İstemci ile orta katman arasındaki aktarım HTTP olduğunda, WF4'te kalıcılık 2,6 kat iyileştirme gösterir. TCP aktarımı bu faktörü 3,0 kata yükseltir. Her durumda orta katmanda CPU kullanımı 98% veya üzeridir. WF4 aktarım hızının daha yüksek olmasının nedeni, daha hızlı iş akışı çalışma zamanı olmasıdır. Seri hale getirilmiş örneğin boyutu her iki durumda da düşüktür ve bu durumda önemli bir katkıda bulunan öğe değildir.

Bu testteki hem WF3 hem de WF4 iş akışları, kalıcılığın ne zaman gerçekleşmesi gerektiğini açıkça belirtmek için bir etkinlik kullanır. Bu, iş akışını devreden çıkarmadan sürekli kılarak avantaj sağlar. WF3'te TimeToUnload özelliği kullanarak kalıcı hale getirmek de mümkündür, ancak bu, iş akışı örneğini bellekten kaldırır. WF3 kullanan bir geliştirici bir iş akışının belirli noktalarda kalıcı olduğundan emin olmak istiyorsa, iş akışı tanımını değiştirmesi veya iş akışı örneğini kaldırıp yeniden yükleme maliyetini ödemesi gerekir. WF4'teki yeni bir özellik, kaldırılmadan kalıcı olmasını sağlar: TimeToPersist. Bu özellik, iş akışı örneğinin boşta kalmasını ancak eşik karşılanana veya yürütme sürdürülene TimeToUnload kadar bellekte kalmasını sağlar.

WF4 SQL kalıcılık sağlayıcısının veritabanı katmanında daha fazla iş gerçekleştirdiğini unutmayın. SQL veritabanı bir performans sorununa dönüşebilir, bu nedenle cpu ve disk kullanımını orada izlemek önemlidir. Performans testi iş akışı uygulamaları sırasında SQL veritabanından aşağıdaki performans sayaçlarını eklediğinizden emin olun:

• PhysicalDisk\%Disk Okuma Süresi

• PhysicalDisk\% Disk Zamanı

• PhysicalDisk\% Disk Yazma Zamanı

• PhysicalDisk\% Ortalama Disk Kuyruğu Uzunluğu

• PhysicalDisk\Avg. Disk Okuma Kuyruğu Uzunluğu

• PhysicalDisk\Ortalama Disk Yazma Kuyruğu Uzunluğu

• PhysicalDisk\Geçerli Disk Kuyruğu Uzunluğu

• İşlemci Bilgileri\% İşlemci Süresi

• SQLServer:Latches\Ortalama Mandal Bekleme Süresi (ms)

• SQLServer:Lıtreler\Bekleme Kilidi Bekleme Süresi/sn

İzleme

İş akışı izleme, bir iş akışının ilerleme durumunu izlemek için kullanılabilir. İzleme olaylarına dahil edilen bilgiler bir izleme profili tarafından belirlenir. İzleme profili ne kadar karmaşık olursa izleme o kadar pahalı olur.

WF3, SQL tabanlı bir izleme hizmetiyle birlikte gönderilir. Bu hizmet, toplu ve toplu olmayan modlarda çalışabilir. Toplu işlenmemiş modda izleme olayları doğrudan veritabanına yazılır. Toplu modda, izleme olayları iş akışı örneği durumuyla aynı toplu işlemde toplanır. Toplu iş akışı modu, en geniş iş akışı tasarımları yelpazesi için en iyi performansa sahiptir. Ancak, birçok etkinlik kalıcı hale gelmeden çalıştırılıyorsa ve bu etkinlikler izleniyorsa, toplama işlemleri olumsuz bir performans etkisine neden olabilir. Bu genellikle döngülerde gerçekleşir ve bu senaryodan kaçınmanın en iyi yolu büyük döngüleri bir kalıcılık noktası içerecek şekilde tasarlamaktır. Bir döngüye kalıcılık noktası eklemek performansı olumsuz etkileyebilir, bu nedenle her birinin maliyetlerini ölçmek ve bir denge oluşturmak önemlidir.

WF4 bir SQL izleme hizmetiyle birlikte gönderilmez. İzleme bilgilerini SQL veritabanına kaydetme, .NET Framework'e yerleşik olarak eklemek yerine bir uygulama sunucusundan daha iyi işlenebilir. Bu nedenle SQL izleme artık AppFabric tarafından işlenir. WF4'teki kullanıma hazır izleme sağlayıcısı, Windows için Olay İzleme'yi (ETW) temel alır.

ETW, Windows'ta yerleşik olarak yer alan çekirdek düzeyinde, düşük gecikme süreli bir olay sistemidir. Yalnızca bir tüketici olduğunda olay izlemenin cezasının verilmesini mümkün kılan bir sağlayıcı/tüketici modeli kullanır. İşlemci, disk, bellek ve ağ kullanımı gibi çekirdek olaylarına ek olarak birçok uygulama da ETW'yi kullanır. ETW olayları, olaylar uygulamada özelleştirilebildiği için performans sayaçlarından daha güçlü olur. Olay, iş akışı kimliği veya bilgilendirme iletisi gibi metinler içerebilir. Ayrıca olaylar bit maskeleri ile kategorilere ayrılmıştır, böylece belirli bir olay alt kümesinin tüketilmesi tüm olayları yakalamaya kıyasla daha az performans etkisine neden olur.

SQL yerine izleme için ETW kullanma yaklaşımının avantajları şunlardır:

• İzleme olaylarının biraraya getirilmesi ayrı bir süreçte gerçekleştirilebilir. Bu, olayların nasıl kaydediliyor konusunda daha fazla esneklik sağlar.

• ETW izleme olayları, WCF ETW olayları veya SQL Server veya çekirdek sağlayıcısı gibi diğer ETW sağlayıcılarıyla kolayca birleştirilir.

• İş akışı yazarlarının WF3 SQL izleme hizmetinin toplu iş modu gibi belirli bir izleme uygulamasıyla daha iyi çalışmak için iş akışını değiştirmeleri gerekmez.

• Yönetici, ana bilgisayar işlemini geri dönüştürmeden izlemeyi açabilir veya kapatabilir.

ETW izlemenin performans avantajları bir dezavantajla birlikte gelir. Sistem yoğun kaynak baskısı altındaysa ETW olayları kaybolabilir. Olayların işlenmesi normal program yürütmesini engellemeye yönelik değildir ve bu nedenle tüm ETW olaylarının abonelerine yayınlanacağı garanti değildir. Bu, ETW izlemenin sistem durumu izleme için mükemmel olmasını ancak denetim için uygun olmamasını sağlar.

WF4'de SQL izleme sağlayıcısı olmasa da AppFabric'in vardır. AppFabric'in SQL izleme yaklaşımı, olayları toplu olarak toplayan ve bunları hızlı eklemeler için tasarlanmış bir SQL tablosuna yazan bir Windows Hizmeti ile ETW olaylarına abone olmaktır. Ayrı bir iş, bu tablodaki verileri alır ve AppFabric panosunda görüntülenebilen raporlama tablolarına dönüştürür. Bu, bir grup izleme olayının geldiği iş akışından bağımsız olarak işlendiği ve bu nedenle kaydedilmeden önce bir kalıcılık noktası beklemesi gerekmediği anlamına gelir.

ETW olayları logman veya xperf gibi araçlarla kaydedilebilir. Kompakt ETL dosyası xperfview gibi bir araçla görüntülenebilir veya tracerpt ile XML gibi daha okunabilir bir biçime dönüştürülebilir. WF3'te, SQL veritabanı olmadan izleme olaylarını almanın tek seçeneği özel bir izleme hizmeti oluşturmaktır. ETW hakkında daha fazla bilgi için bkz. WCF Hizmetleri ve Windows için Olay İzleme ve Olay İzleme - Windows uygulamaları.

İş akışı izlemenin etkinleştirilmesi, performansı değişen derecelerde etkiler. Aşağıdaki kıyaslama, logman aracını kullanarak ETW izleme olaylarını tüketir ve bunları bir ETL dosyasına kaydeder. AppFabric'teki SQL izlemenin maliyeti bu makalenin kapsamında değildir. AppFabric'te de kullanılan temel izleme profili bu karşılaştırmada gösterilmiştir. Ayrıca yalnızca sağlık izleme olaylarını izleme maliyeti de dahildir. Bu olaylar sorunları gidermek ve sistemin ortalama aktarım hızını belirlemek için yararlıdır.

Ortam Kurulumu

Test Sonuçları

Sağlık izlemenin verim üzerinde yaklaşık 3% etkisi vardır. Temel profilin maliyeti yaklaşık 8%.

Birlikte Çalışma

WF4, WF'nin neredeyse tamamen yeniden yazılmasıdır ve bu nedenle WF3 iş akışları ve etkinlikleri WF4 ile doğrudan uyumlu değildir. Windows Workflow Foundation'ı erken benimseyen birçok müşterinin şirket içi veya üçüncü taraf iş akışı tanımları ve WF3 için özel etkinlikleri olacaktır. WF4'e geçişi kolaylaştırma yollarından biri, WF3 etkinliklerini bir WF4 iş akışı içinden yürütebilen Birlikte Çalışma etkinliğini kullanmaktır. Interop etkinliğinin yalnızca gerektiğinde kullanılması önerilir. WF4'e geçiş hakkında daha fazla bilgi için WF4 Geçiş Kılavuzu'na bakın.

Ortam Kurulumu

Test Sonuçları

Aşağıdaki tabloda, çeşitli yapılandırmalarda bir dizide beş etkinlik içeren bir iş akışını çalıştırmanın sonuçları gösterilmektedir.

Sınav	Aktarım hızı (iş akışları/sn)
WF3 çalışma zamanında WF3 Sırası	1,576
Interop Kullanarak WF4 Çalışma Zamanında WF3 Sıralaması	2.745
WF4 Dizisi	153,582

Interop'un doğrudan WF3'e göre kullanılmasında önemli bir performans artışı vardır. Ancak WF4 etkinliklerine kıyasla artış göz ardı edilebilir.

Özet

WF4 için büyük performans yatırımları birçok önemli alanda karşılığını verdi. Daha yalın bir WF çalışma zamanı nedeniyle WF4'te tek tek iş akışı bileşeni performansı WF3'e kıyasla yüzlerce kat daha hızlıdır. Gecikme süresi sayıları da önemli ölçüde daha iyidir. Bu, WF kullanmanın sağladığı ek avantajlar göz önüne alındığında, WCF düzenleme hizmetlerini elle kodlamaya kıyasla WF kullanmanın performans cezasının çok küçük olduğu anlamına gelir. Kalıcılık performansı 2,5 - 3,0 kat arttı. İş akışı izleme yoluyla sağlık durumunun izlenmesi artık çok az ek yüke sahiptir. WF3'ten WF4'e geçmeyi düşünenler için kapsamlı bir geçiş kılavuzları kümesi mevcuttur. Tüm bunlar WF4'ün karmaşık uygulamalar yazmak için cazip bir seçenek olmasını sağlamalıdır.