Kinerja Windows Workflow Foundation 4

.NET Framework 4 mencakup revisi utama Windows Workflow Foundation (WF) dengan investasi berat dalam performa. Revisi baru ini memperkenalkan perubahan desain yang signifikan dari versi WF sebelumnya yang dikirim sebagai bagian dari .NET Framework 3.0 dan .NET Framework 3.5. Telah didesain ulang dari inti model pemrograman, runtime, dan alat untuk sangat meningkatkan performa dan kegunaan. Topik ini menunjukkan karakteristik performa penting dari revisi ini dan membandingkannya dengan versi sebelumnya.

Performa dari setiap komponen alur kerja telah meningkat dengan skala tertentu antara WF3 dan WF4. Ini meninggalkan kesenjangan antara layanan Windows Communication Foundation (WCF) berkode tangan dan layanan alur kerja WCF menjadi cukup kecil. Latensi alur kerja telah berkurang secara signifikan di WF4. Performa persistensi meningkat dengan faktor 2,5 - 3,0. Pemantauan kesehatan dengan cara pelacakan alur kerja memiliki overhead yang jauh lebih sedikit. Ini adalah alasan kuat untuk bermigrasi ke atau mengadopsi WF4 dalam aplikasi Anda.

Terminologi

Versi WF yang diperkenalkan dalam .NET Framework 4 akan disebut sebagai WF4 untuk sisa topik ini. WF diperkenalkan dalam .NET Framework 3.0 dan memiliki beberapa revisi kecil melalui .NET Framework 3.5 SP1. Versi .NET Framework 3.5 dari Workflow Foundation akan disebut sebagai WF3 untuk sisa topik ini. WF3 dikirim dalam .NET Framework 4 berdampingan dengan WF4. Untuk informasi selengkapnya tentang memigrasikan artefak WF3 ke WF4 lihat: Panduan Migrasi Windows Workflow Foundation 4.

Windows Communication Foundation (WCF) adalah model pemrograman terpadu Microsoft untuk membangun aplikasi berorientasi layanan. Ini pertama kali diperkenalkan sebagai bagian dari .NET Framework 3.0 bersama dengan WF3 dan sekarang merupakan salah satu komponen utama dari .NET Framework.

Windows Server AppFabric adalah sekumpulan teknologi terintegrasi yang memudahkan untuk membangun, menskalakan, dan mengelola aplikasi Web dan komposit yang berjalan di IIS. Ini menyediakan alat untuk memantau dan mengelola layanan dan alur kerja. Untuk informasi selengkapnya, lihat Windows Server AppFabric 1.0.

Tujuan

Tujuan dari topik ini adalah untuk menunjukkan karakteristik performa WF4 dengan data yang diukur untuk skenario yang berbeda. Ini juga memberikan perbandingan terperinci antara WF4 dan WF3, dan dengan demikian menunjukkan peningkatan besar yang telah dilakukan dalam revisi baru ini. Skenario dan data yang disajikan dalam artikel ini mengukur biaya yang mendasari berbagai aspek WF4 dan WF3. Data ini berguna dalam memahami karakteristik performa WF4 dan dapat membantu dalam merencanakan migrasi dari WF3 ke WF4 atau menggunakan WF4 dalam pengembangan aplikasi. Namun, perhatian harus diberikan dalam kesimpulan yang dibuat dari data yang disajikan dalam artikel ini. Performa aplikasi alur kerja komposit sangat bergantung pada bagaimana alur kerja diimplementasikan dan bagaimana komponen yang berbeda terintegrasi. Seseorang harus mengukur setiap aplikasi untuk menentukan karakteristik performa aplikasi tersebut.

Gambaran Umum Peningkatan Performa WF4

WF4 dirancang dan diimplementasikan dengan hati-hati dengan performa dan skalabilitas tinggi yang dijelaskan di bagian berikut.

WF Runtime

Pada inti runtime WF adalah penjadwal asinkron yang mendorong eksekusi aktivitas dalam alur kerja. Ini menyediakan lingkungan eksekusi yang berkinerja dan dapat diprediksi untuk aktivitas. Sistem memiliki kontrak yang terdefinisi dengan baik untuk eksekusi, kelanjutan, penyelesaian, pembatalan, pengecualian, dan model penanganan thread yang dapat diprediksi.

Dibandingkan dengan WF3, runtime WF4 memiliki penjadwal yang lebih efisien. Ini memanfaatkan kumpulan utas I/O yang sama yang digunakan untuk WCF, yang sangat efisien dalam mengeksekusi item pekerjaan yang diproses secara batch. Antrean penjadwal item kerja internal dioptimalkan untuk pola penggunaan yang paling umum. Runtime WF4 juga mengelola status eksekusi dengan cara yang sangat ringan dengan sinkronisasi minimal dan logika penanganan peristiwa, sementara WF3 tergantung pada pendaftaran peristiwa berat dan pemanggilan untuk melakukan sinkronisasi kompleks untuk transisi status.

Penyimpanan dan Aliran Data

Di WF3, data yang terkait dengan aktivitas dimodelkan melalui properti dependensi yang diterapkan oleh jenis DependencyProperty. Pola properti dependensi diperkenalkan di Windows Presentation Foundation (WPF). Secara umum, pola ini sangat fleksibel untuk mendukung pengikatan data yang mudah dan fitur UI lainnya. Namun, pola mengharuskan properti didefinisikan sebagai bidang statis dalam definisi alur kerja. Setiap kali runtime WF menetapkan atau mendapatkan nilai properti, itu melibatkan logika pencarian yang berat.

WF4 menggunakan logika cakupan data yang jelas untuk sangat meningkatkan cara data ditangani dalam alur kerja. Ini memisahkan data yang disimpan dalam aktivitas dari data yang mengalir di seluruh batas aktivitas dengan menggunakan dua konsep berbeda: variabel dan argumen. Dengan menggunakan cakupan hierarkis yang jelas untuk variabel dan argumen "Input/Output/InOut", kompleksitas penggunaan data untuk aktivitas berkurang secara dramatis dan masa pakai data juga secara otomatis ditentukan cakupannya. Aktivitas-aktivitas memiliki ciri khas yang terdefinisi dengan baik yang dijelaskan oleh argumennya. Dengan hanya memeriksa aktivitas, Anda dapat menentukan data apa yang diharapkan untuk diterima dan data apa yang akan dihasilkan olehnya sebagai hasil dari eksekusinya.

Aktivitas di WF3 diinisialisasi ketika alur kerja dibuat. Di WF 4, aktivitas-aktivitas diinisialisasi hanya saat aktivitas yang bersangkutan sedang dijalankan. Ini memungkinkan siklus hidup aktivitas yang lebih sederhana tanpa perlu melakukan operasi Inisialisasi maupun Pembatalan Inisialisasi saat instans alur kerja baru dibuat, sehingga mencapai efisiensi yang lebih tinggi.

Alur Kontrol

Sama seperti dalam bahasa pemrograman apa pun, WF menyediakan dukungan untuk alur kontrol untuk definisi alur kerja dengan memperkenalkan serangkaian aktivitas alur kontrol untuk pengurutan, perulangan, percabangan, dan pola lainnya. Di WF3, ketika aktivitas yang sama perlu dijalankan kembali, sebuah ActivityExecutionContext baru dibuat dan aktivitas tersebut dikloning melalui logika serialisasi dan deserialisasi yang berat berdasarkan BinaryFormatter. Biasanya performa untuk alur kontrol iteratif jauh lebih lambat daripada menjalankan urutan aktivitas.

WF4 menangani ini cukup berbeda. Templat aktivitas diambil, objek ActivityInstance baru dibuat, dan ditambahkan ke antrean penjadwal. Seluruh proses ini hanya melibatkan pembuatan objek eksplisit dan sangat ringan.

Pemrograman Asinkron

Aplikasi biasanya memiliki performa dan skalabilitas yang lebih baik dengan pemrograman asinkron untuk operasi pemblokiran jangka panjang seperti I/O atau operasi komputasi terdistribusi. WF4 menyediakan dukungan asinkron melalui jenis aktivitas dasar AsyncCodeActivity, AsyncCodeActivity<TResult>. Runtime secara bawaan memahami aktivitas asinkron dan oleh karena itu dapat secara otomatis menempatkan instans di zona tanpa persisten sementara pekerjaan asinkron belum selesai. Aktivitas kustom dapat dibuat dari jenis ini untuk melakukan tugas asinkron tanpa menahan thread penjadwal alur kerja sehingga tidak memblokir aktivitas apa pun yang mungkin dapat berjalan secara paralel.

Pesan

Awalnya WF3 memiliki dukungan olahpesan yang sangat terbatas melalui peristiwa eksternal atau pemanggilan layanan web. Dalam .NET Framework 3.5, alur kerja dapat diimplementasikan sebagai klien WCF atau diekspos sebagai layanan WCF melalui SendActivity dan ReceiveActivity. Di WF4, konsep pemrograman olahpesan berbasis alur kerja telah diperkuat lebih lanjut melalui integrasi ketat logika olahpesan WCF ke WF.

Alur pemrosesan pesan terpadu yang disediakan dalam WCF di .NET 4 membantu layanan WF4 memiliki performa dan skalabilitas yang jauh lebih baik daripada WF3. WF4 juga menyediakan dukungan pemrograman olahpesan yang lebih kaya yang dapat memodelkan Pola Pertukaran Pesan (MEP) yang kompleks. Pengembang dapat menggunakan kontrak layanan jenis untuk mencapai pemrograman yang mudah atau kontrak layanan yang tidak dijenis untuk mencapai performa yang lebih baik tanpa membayar biaya serialisasi. Dukungan caching saluran sisi klien melalui kelas SendMessageChannelCache di WF4 membantu pengembang membangun aplikasi cepat dengan upaya minimal. Untuk informasi selengkapnya, lihat Mengubah Tingkat Berbagi Cache untuk Aktivitas Kirim.

Pemrograman Deklaratif

WF4 menyediakan kerangka kerja pemrograman deklaratif yang bersih dan sederhana untuk memodelkan proses dan layanan bisnis. Model pemrograman mendukung komposisi aktivitas yang sepenuhnya deklaratif, tanpa kode di samping, sangat menyederhanakan penulisan alur kerja. Dalam .NET Framework 4, kerangka kerja pemrograman deklaratif berbasis XAML telah disatukan ke dalam rakitan tunggal System.Xaml.dll untuk mendukung WPF dan WF.

Di WF4, XAML memberikan pengalaman yang benar-benar deklaratif dan memungkinkan seluruh definisi alur kerja ditentukan dalam markup XML, mereferensikan aktivitas dan jenis yang dibangun menggunakan .NET. Ini sulit dilakukan dalam WF3 dengan format XOML tanpa melibatkan logika di balik kode kustom. XAML-stack baru di .NET 4 memiliki performa yang jauh lebih baik dalam menserialisasikan/mendeserialisasi artefak alur kerja dan membuat pemrograman deklaratif lebih menarik dan solid.

Perancang Alur Kerja

Dukungan pemrograman yang sepenuhnya deklaratif untuk WF4 secara eksplisit memberlakukan persyaratan yang lebih tinggi untuk performa waktu desain untuk alur kerja besar. Perancang Alur Kerja di WF4 memiliki skalabilitas yang jauh lebih baik untuk alur kerja besar daripada yang untuk WF3. Dengan dukungan virtualisasi UI, perancang dapat dengan mudah memuat alur kerja besar 1000 aktivitas dalam beberapa detik, sementara hampir tidak mungkin untuk memuat alur kerja beberapa ratus aktivitas dengan perancang WF3.

Perbandingan Performa Tingkat Komponen

Bagian ini berisi data tentang perbandingan langsung antara aktivitas individual dalam alur kerja WF3 dan WF4. Area utama seperti persistensi memiliki dampak yang lebih mendalam pada performa daripada komponen aktivitas individu. Peningkatan performa dalam komponen individu di WF4 penting karena komponen sekarang cukup cepat untuk dibandingkan dengan logika orkestrasi berkode tangan. Contoh yang dibahas di bagian berikutnya: "Skenario Komposisi Layanan."

Penyiapan Lingkungan

Gambar di atas menunjukkan konfigurasi komputer yang digunakan untuk pengukuran performa tingkat komponen. Satu server dan lima klien terhubung melalui satu antarmuka jaringan Ethernet 1 Gbps. Untuk pengukuran yang mudah, server dikonfigurasi untuk menggunakan satu inti server dual-proc/quad-core yang menjalankan Windows Server 2008 x86. Pemanfaatan CPU sistem dipertahankan pada hampir 100%.

Detail pengujian

WF3 CodeActivity kemungkinan adalah aktivitas paling sederhana yang dapat digunakan dalam alur kerja WF3. Aktivitas memanggil metode di backend kode yang memungkinkan pemrogram alur kerja untuk memasukkan kode kustom. Di WF4, tidak ada analog langsung ke WF3 CodeActivity yang menyediakan fungsionalitas yang sama. Perhatikan bahwa ada CodeActivity kelas dasar di WF4 yang tidak terkait dengan WF3 CodeActivity. Penulis alur kerja didorong untuk membuat aktivitas kustom dan membangun alur kerja khusus XAML. Dalam pengujian di bawah ini, aktivitas yang disebut Comment digunakan sebagai pengganti alur kerja WF4 kosong CodeActivity . Kode dalam Comment aktivitas adalah sebagai berikut:

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

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

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Alur Kerja Kosong

Pengujian ini menggunakan alur kerja urutan tanpa aktivitas anak.

Aktivitas Tunggal

Alur kerja adalah alur kerja urutan yang berisi satu aktivitas anak. Aktivitas ini adalah CodeActivity tanpa kode dalam kasus WF3 dan aktivitas Comment dalam kasus WF4.

Saat menjalani 1000 iterasi

Alur kerja urutan berisi satu While aktivitas dengan satu aktivitas anak dalam perulangan yang tidak melakukan pekerjaan apa pun.

Replikator dibandingkan dengan ParallelForEach

ReplicatorActivity dalam WF3 memiliki mode eksekusi berurutan dan paralel. Dalam mode berurutan, performa aktivitas mirip dengan WhileActivity. ReplicatorActivity ini paling bermanfaat untuk eksekusi paralel. Analog WF4 untuk ini adalah aktivitas ParallelForEach<T>.

Diagram berikut menunjukkan alur kerja yang digunakan untuk pengujian ini. Alur kerja WF3 berada di sebelah kiri dan alur kerja WF4 berada di sebelah kanan.

Alur Kerja Berurutan dengan Lima Aktivitas

Pengujian ini dimaksudkan untuk menunjukkan efek memiliki beberapa aktivitas yang dijalankan secara berurutan. Ada lima kegiatan secara berurutan.

Cakupan Transaksi

Pengujian cakupan transaksi sedikit berbeda dari pengujian lain karena instans alur kerja baru tidak dibuat untuk setiap perulangan. Sebagai gantinya, alur kerja disusun dengan perulangan 'while' yang berisi TransactionScope aktivitas tunggal yang tidak melakukan pekerjaan apa pun. Setiap eksekusi batch 50 iterasi melalui perulangan 'while' dihitung sebagai operasi tunggal.

Kompensasi

Alur kerja WF3 memiliki satu aktivitas yang dapat dikompensasi bernama WorkScope. Aktivitas hanya mengimplementasikan ICompensatableActivity antarmuka:

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

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

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

Penangan kesalahan menargetkan aktivitas WorkScope. Alur kerja WF4 sama-sama sederhana. A CompensableActivity memiliki tubuh dan handler kompensasi. Kompensasi eksplisit berikutnya dalam urutan. Aktivitas badan dan aktivitas penanganan kompensasi keduanya merupakan implementasi yang kosong.

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

Diagram berikut menunjukkan alur kerja kompensasi dasar. Alur kerja WF3 berada di sebelah kiri dan alur kerja WF4 berada di sebelah kanan.

Hasil Pengujian Performa

Semua pengujian diukur dalam alur kerja per detik dengan pengecualian pengujian cakupan transaksi. Seperti yang dapat dilihat di atas, performa runtime WF telah meningkat secara keseluruhan, terutama di area yang memerlukan beberapa eksekusi aktivitas yang sama seperti while loop.

Skenario Komposisi Layanan

Seperti yang ditunjukkan di bagian sebelumnya, "Perbandingan Performa Tingkat Komponen," telah ada pengurangan overhead yang signifikan antara WF3 dan WF4. Layanan alur kerja WCF kini hampir dapat menyamai performa layanan WCF yang dikode secara manual, namun tetap memiliki semua manfaat dari runtime WF. Skenario pengujian ini membandingkan layanan WCF dengan layanan alur kerja WCF di WF4.

Layanan Toko Online

Salah satu kekuatan Windows Workflow Foundation adalah kemampuan untuk menyusun proses menggunakan beberapa layanan. Untuk contoh ini, ada layanan toko online yang mengatur dua panggilan layanan untuk membeli pesanan. Langkah pertama adalah memvalidasi pesanan menggunakan Layanan Validasi Pesanan. Langkah kedua adalah mengisi pesanan menggunakan Warehouse Service.

Dua layanan backend, Layanan Validasi Pesanan dan Layanan Gudang, tetap sama untuk kedua pengujian. Bagian yang berubah adalah Layanan Toko Online yang melakukan orkestrasi. Dalam satu kasus, layanan ini dikodekan dengan tangan sebagai layanan WCF. Untuk kasus lain, layanan ditulis sebagai layanan alur kerja WCF di WF4. Fitur khusus WF seperti pelacakan dan persistensi dinonaktifkan untuk pengujian ini.

Lingkungan

Permintaan klien dibuat ke Layanan Toko Online melalui HTTP dari beberapa komputer. Satu komputer menghosting ketiga layanan. Lapisan transportasi antara Layanan Toko Online dan layanan backend adalah TCP atau HTTP. Pengukuran operasi/detik didasarkan pada jumlah panggilan yang telah diselesaikan PurchaseOrder ke Layanan Toko Online. Pengumpulan saluran adalah fitur baru yang tersedia di WF4. Dalam bagian WCF dari pengujian ini, pengumpulan saluran tidak disediakan secara default sehingga implementasi yang ditulis secara manual dari teknik pengumpulan sederhana digunakan dalam Layanan Toko Online.

Penampilan

Menghubungkan dengan layanan TCP backend tanpa penggunaan saluran bersama, layanan WF memiliki dampak 17,2% pada throughput. Dengan pengumpulan saluran, penalti sekitar 23,8%. Untuk HTTP, dampaknya jauh lebih sedikit: 4,3% tanpa pengumpulan dan 8,1% dengan pengumpulan. Penting juga untuk dicatat bahwa pengumpulan saluran memberikan manfaat yang sangat sedikit saat menggunakan HTTP.

Meskipun ada overhead dari runtime WF4 dibandingkan dengan layanan WCF berkode tangan dalam pengujian ini, itu dapat dianggap sebagai skenario terburuk. Dua layanan backend dalam pengujian ini melakukan pekerjaan yang sangat sedikit. Dalam skenario end-to-end nyata, layanan ini akan melakukan operasi yang lebih mahal seperti panggilan database, membuat dampak performa lapisan transportasi kurang penting. Ini ditambah manfaat fitur yang tersedia di WF4 menjadikan Workflow Foundation pilihan yang layak untuk membuat layanan orkestrasi.

Pertimbangan Performa Utama

Area fitur di bagian ini, dengan pengecualian interop, telah berubah secara dramatis antara WF3 dan WF4. Hal ini memengaruhi desain aplikasi alur kerja serta performa.

Latensi Aktivasi Alur Kerja

Dalam aplikasi layanan alur kerja WCF, latensi untuk memulai alur kerja baru atau memuat alur kerja yang ada penting karena dapat memblokir. Kasus pengujian ini mengukur host WF3 XOML terhadap host WF4 XAMLX dalam skenario umum.

Penyiapan Lingkungan

Penyetelan Pengujian

Dalam skenario, komputer klien menghubungi layanan alur kerja WCF menggunakan korelasi berbasis konteks. Korelasi konteks memerlukan pengikatan konteks khusus dan menggunakan header konteks atau cookie untuk menghubungkan pesan ke instans alur kerja yang benar. Ini memiliki manfaat performa karena Id korelasi terletak di header pesan sehingga isi pesan tidak perlu diurai.

Layanan akan membuat alur kerja baru dengan permintaan dan mengirim respons langsung sehingga pengukuran latensi tidak termasuk waktu yang dihabiskan untuk menjalankan alur kerja. Alur kerja WF3 adalah XOML dengan kode di belakang dan alur kerja WF4 sepenuhnya XAML. Alur kerja WF4 terlihat seperti ini:

Aktivitas Receive membuat instance alur kerja. Nilai yang diteruskan dalam pesan yang diterima dicerminkan kembali dalam pesan balasan. Urutan setelah balasan berisi sisa alur kerja. Dalam kasus di atas, hanya satu aktivitas komentar yang ditampilkan. Jumlah aktivitas komentar diubah untuk mensimulasikan kompleksitas alur kerja. Aktivitas komentar setara dengan sebuah WF3 CodeActivity yang tidak melakukan apa-apa. Untuk informasi selengkapnya tentang aktivitas komentar, lihat bagian "Perbandingan Performa Tingkat Komponen" sebelumnya di artikel ini.

Hasil Pengujian

Latensi dingin dan hangat untuk layanan alur kerja WCF:

Di bagan sebelumnya, istilah "cold" mengacu pada kasus di mana tidak ada WorkflowServiceHost yang ada untuk alur kerja tertentu yang diberikan. Dengan kata lain, latensi dingin adalah ketika alur kerja digunakan untuk pertama kalinya dan XOML atau XAML perlu dikompilasi. Latensi hangat adalah waktu untuk membuat instans alur kerja baru ketika jenis alur kerja telah dikompilasi. Kompleksitas alur kerja membuat sangat sedikit perbedaan dalam kasus WF4 tetapi memiliki perkembangan linier dalam kasus WF3.

Korelasi Throughput

WF4 memperkenalkan fitur korelasi berbasis konten baru. WF3 hanya menyediakan korelasi berbasis konteks. Korelasi berbasis konteks hanya dapat dilakukan melalui pengikatan saluran WCF tertentu. Id alur kerja disisipkan ke header pesan saat menggunakan pengikatan ini. Runtime WF3 hanya dapat mengidentifikasi alur kerja dengan Id-nya. Dengan korelasi berbasis konten, penulis alur kerja dapat membuat kunci korelasi dari bagian data yang relevan seperti nomor akun atau Id pelanggan.

Korelasi berbasis konteks memiliki keunggulan performa karena kunci korelasi terletak di header pesan. Kunci dapat dibaca dari pesan tanpa melakukan de-serialisasi atau penyalinan pesan. Dalam korelasi berbasis konten, kunci korelasi disimpan dalam isi pesan. Ekspresi XPath digunakan untuk menemukan kunci. Biaya pemrosesan tambahan ini tergantung pada ukuran pesan, kedalaman kunci dalam isi, dan jumlah kunci. Pengujian ini membandingkan korelasi berbasis konteks dan konten dan juga menunjukkan penurunan performa saat menggunakan beberapa kunci.

Penyiapan Lingkungan

Penyetelan Pengujian

Alur kerja sebelumnya sama dengan yang digunakan di bagian Persistensi . Untuk pengujian korelasi tanpa persistensi, tidak ada penyedia persistensi yang diinstal dalam runtime. Korelasi terjadi di dua tempat: CreateOrder dan CompleteOrder.

Hasil Pengujian

Grafik ini menunjukkan penurunan performa karena jumlah kunci yang digunakan dalam korelasi berbasis konten meningkat. Kesamaan kurva antara TCP dan HTTP menunjukkan overhead yang terkait dengan protokol ini.

Korelasi dengan Persistensi

Dengan alur kerja yang bertahan, tekanan CPU akibat pergeseran korelasi yang berbasis konten berpindah dari runtime alur kerja ke database SQL. Prosedur tersimpan di penyedia persistensi SQL melakukan pekerjaan pencocokan kunci untuk menemukan alur kerja yang sesuai.

Korelasi berbasis konteks masih lebih cepat daripada korelasi berbasis konten. Namun, perbedaannya kurang jelas karena persistensi memiliki dampak lebih besar pada performa daripada korelasi.

Laju Pemrosesan Alur Kerja Kompleks

Kompleksitas alur kerja tidak diukur hanya dengan jumlah aktivitas. Kegiatan komposit dapat mengandung banyak anak dan anak-anak tersebut juga dapat menjadi kegiatan komposit. Ketika jumlah tingkat bersarang meningkat, begitu pula jumlah aktivitas yang saat ini dapat berada dalam keadaan eksekusi dan jumlah variabel yang dapat berada dalam keadaan. Pengujian ini membandingkan throughput antara WF3 dan WF4 saat menjalankan alur kerja yang kompleks.

Penyetelan Pengujian

Pengujian ini dijalankan pada komputer Intel Xeon X5355 @ 2.66GHz 4-way dengan RAM 4GB yang menjalankan Windows Server 2008 x64. Kode pengujian berjalan dalam satu proses dengan satu thread untuk setiap inti untuk mencapai penggunaan CPU 100%.

Alur kerja yang dihasilkan untuk pengujian ini memiliki dua variabel utama: kedalaman dan jumlah aktivitas dalam setiap urutan. Setiap tingkat kedalaman mencakup aktivitas paralel, perulangan while, keputusan, penugasan, dan urutan. Dalam perancang WF4 yang terlihat pada gambar di bawah ini, diagram alur tingkat atas diperlihatkan. Setiap aktivitas diagram alir menyerupai diagram alir utama. Mungkin berguna untuk memikirkan fraktal saat membayangkan alur kerja ini, di mana kedalaman terbatas pada parameter pengujian.

Jumlah aktivitas dalam tes tertentu ditentukan oleh kedalaman dan jumlah aktivitas per urutan. Persamaan berikut menghitung jumlah aktivitas dalam pengujian WF4:

Jumlah aktivitas pengujian WF3 dapat dihitung dengan persamaan yang sedikit berbeda karena urutan tambahan:

Di mana d adalah kedalaman dan adalah jumlah aktivitas per urutan. Logika di balik persamaan ini adalah bahwa konstanta pertama, dikalikan dengan, adalah jumlah urutan dan konstanta kedua adalah jumlah aktivitas statis dalam tingkat saat ini. Ada tiga aktivitas anak diagram alur di setiap diagram alur. Pada tingkat kedalaman bawah, diagram alur ini kosong tetapi pada tingkat lain mereka adalah salinan diagram alur utama. Jumlah aktivitas dalam setiap definisi alur kerja variasi pengujian ditunjukkan dalam tabel berikut:

Jumlah aktivitas dalam definisi alur kerja meningkat tajam dengan setiap tingkat kedalaman. Tetapi hanya satu jalur per titik keputusan yang dijalankan dalam instans alur kerja tertentu, sehingga hanya subset kecil dari aktivitas aktual yang dijalankan.

Alur kerja yang setara dibuat untuk WF3. Perancang WF3 menunjukkan seluruh alur kerja di area desain alih-alih membuat sarang, sehingga terlalu besar untuk diperlihatkan dalam topik ini. Cuplikan alur kerja ditunjukkan di bawah ini.

Untuk menguji penumpukan dalam kasus ekstrem, alur kerja lain yang merupakan bagian dari pengujian ini menggunakan 100 urutan tumpukan. Dalam urutan terdalam adalah satu Comment atau CodeActivity.

Pelacakan dan persistensi tidak digunakan sebagai bagian dari pengujian ini.

Hasil Pengujian

Bahkan dengan alur kerja yang kompleks dengan banyak kedalaman dan jumlah aktivitas yang tinggi, hasil performa konsisten dengan angka throughput lain yang ditunjukkan sebelumnya dalam artikel ini. Throughput WF4 berlipat-lipat kali lebih cepat dan harus dibandingkan pada skala logaritma.

Ingatan

Overhead memori Windows Workflow Foundation diukur dalam dua area utama: kompleksitas alur kerja dan jumlah definisi alur kerja. Pengukuran memori diambil pada stasiun kerja Windows 7 64-bit. Ada banyak cara untuk mendapatkan pengukuran ukuran set kerja seperti memantau penghitung kinerja, polling Environment.WorkingSet, atau menggunakan alat seperti VMMap yang tersedia dari VMMap. Kombinasi metode digunakan untuk mendapatkan dan memverifikasi hasil setiap pengujian.

Uji Kompleksitas Alur Kerja

Uji kompleksitas alur kerja mengukur perbedaan set kerja berdasarkan kompleksitas alur kerja. Selain alur kerja kompleks yang digunakan di bagian sebelumnya, variasi baru ditambahkan untuk mencakup dua kasus dasar: satu alur kerja aktivitas dan urutan dengan 1000 aktivitas. Untuk pengujian ini, alur kerja diinisialisasi dan dijalankan hingga selesai dalam satu perulangan seri untuk jangka waktu satu menit. Setiap variasi pengujian dijalankan tiga kali dan data yang direkam adalah rata-rata dari ketiga eksekusi tersebut.

Dua pengujian dasar baru memiliki alur kerja yang terlihat seperti yang ditunjukkan di bawah ini:

Dalam alur kerja WF3 yang ditunjukkan di atas, aktivitas kosong CodeActivity digunakan. Alur kerja WF4 di atas menggunakan Comment aktivitas. Aktivitas Comment ini dijelaskan di bagian Perbandingan Performa Tingkat Komponen sebelumnya di artikel ini.

Salah satu tren yang jelas untuk diperhatikan dalam grafik ini adalah bahwa bersarang memiliki dampak yang relatif minimal pada penggunaan memori di WF3 dan WF4. Dampak memori yang paling signifikan berasal dari jumlah aktivitas dalam alur kerja tertentu. Mengingat data dari urutan 1000, kedalaman kompleks 5 urutan 5, dan kedalaman kompleks 7 urutan 1 variasi, jelas bahwa ketika jumlah aktivitas memasuki ribuan, peningkatan penggunaan memori menjadi lebih terlihat. Dalam kasus ekstrem (kedalaman 7 urutan 1) di mana ada ~29K aktivitas, WF4 menggunakan hampir 79% lebih sedikit memori daripada WF3.

Pengujian Definisi Beberapa Alur Kerja

Pengukuran memori untuk setiap definisi alur kerja dibagi menjadi dua jenis pengujian yang berbeda berdasarkan opsi yang tersedia untuk menghosting alur kerja di WF3 dan WF4. Pengujian dijalankan dengan cara yang berbeda dari pengujian kompleksitas alur kerja di mana alur kerja tertentu di-instans dan dijalankan hanya sekali per definisi. Ini karena definisi alur kerja dan hostnya tetap berada dalam memori selama masa pakai AppDomain. Memori yang digunakan dengan menjalankan instans alur kerja tertentu harus dibersihkan selama pengumpulan sampah. Panduan migrasi untuk WF4 berisi informasi yang lebih rinci tentang opsi hosting. Untuk informasi selengkapnya, lihat Panduan Migrasi WF: Hosting Alur Kerja.

Membuat banyak definisi alur kerja untuk pengujian definisi alur kerja dapat dilakukan dengan beberapa cara. Misalnya, seseorang dapat menggunakan pembuatan kode untuk membuat sekumpulan 1000 alur kerja yang identik kecuali dalam nama dan menyimpan masing-masing alur kerja tersebut ke dalam file terpisah. Pendekatan ini diambil untuk pengujian yang dihosting konsol. Di WF3, WorkflowRuntime kelas digunakan untuk menjalankan definisi alur kerja. WF4 dapat digunakan WorkflowApplication untuk membuat instans alur kerja tunggal atau langsung digunakan WorkflowInvoker untuk menjalankan aktivitas seolah-olah itu adalah panggilan metode. WorkflowApplication adalah host dari instans alur kerja tunggal dan memiliki kesetaraan fitur yang lebih dekat dengan WorkflowRuntime, dan karenanya digunakan dalam pengujian ini.

Saat menghosting alur kerja di IIS, Anda dapat menggunakan VirtualPathProvider untuk membuat yang baru WorkflowServiceHost alih-alih menghasilkan semua file XAMLX atau XOML. VirtualPathProvider menangani permintaan masuk dan merespons dengan "file virtual" yang dapat dimuat dari database atau, pada kasus ini, dihasilkan secara instan. Oleh karena itu, tidak perlu membuat 1000 file fisik.

Definisi alur kerja yang digunakan dalam pengujian konsol adalah alur kerja berurutan sederhana dengan satu aktivitas. Aktivitas tunggal berupa CodeActivity kosong untuk kasus WF3 dan aktivitas Comment untuk kasus WF4. Kasus yang dihosting IIS menggunakan alur kerja yang mulai menerima pesan dan berakhir pada pengiriman balasan:

Gambar berikut menunjukkan alur kerja WF3 dengan ReceiveActivity dan alur kerja WF4 dengan pola permintaan/respons:

Tabel berikut ini memperlihatkan delta dalam kumpulan kerja antara satu definisi alur kerja dan 1001 definisi:

Pilihan Hosting	Set Kerja Delta WF3	Delta Set Kerja WF4
Alur Kerja yang Dihost di Aplikasi Konsol	18 MB	9 MB
Layanan Alur Kerja yang Dihosting IIS	446 MB	364 MB

Definisi alur kerja yang dihosting di IIS mengonsumsi lebih banyak memori akibat artefak layanan WCF yang terperinci dan logika pemrosesan pesan yang terkait dengan host.

Untuk hosting konsol di WF3, alur kerja diimplementasikan dalam kode alih-alih XOML. Di WF4, defaultnya adalah menggunakan XAML. XAML disimpan sebagai sumber daya yang disematkan dalam rakitan dan dikompilasi selama runtime untuk menyediakan implementasi alur kerja. Ada beberapa overhead yang terkait dengan proses ini. Untuk membuat perbandingan yang adil antara WF3 dan WF4, alur kerja berkode digunakan alih-alih XAML. Contoh salah satu alur kerja WF4 ditunjukkan di bawah ini:

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

Ada banyak faktor lain yang dapat memengaruhi konsumsi memori. Saran yang sama untuk semua program terkelola masih berlaku. Di lingkungan yang dihosting IIS, WorkflowServiceHost objek yang dibuat untuk definisi alur kerja tetap dalam memori hingga kumpulan aplikasi didaur ulang. Ini harus diingat saat menulis ekstensi. Selain itu, yang terbaik adalah menghindari variabel "global" (variabel yang terlingkup ke seluruh alur kerja) dan membatasi cakupan variabel sedapat mungkin.

Layanan Runtime Alur Kerja

Keteguhan

WF3 dan WF4 sudah termasuk penyedia persistensi SQL. Penyedia persistensi WF3 SQL adalah implementasi sederhana yang menserialisasikan instans alur kerja dan menyimpannya dalam blob. Untuk alasan ini, performa penyedia ini sangat bergantung pada ukuran instans alur kerja. Di WF3, ukuran instans dapat meningkat karena berbagai alasan, seperti yang dibahas sebelumnya dalam makalah ini. Banyak pelanggan memilih untuk tidak menggunakan penyedia persistensi SQL default karena menyimpan instans berseri dalam database tidak memberikan visibilitas ke dalam status alur kerja. Untuk menemukan alur kerja tertentu tanpa mengetahui id alur kerja, seseorang harus melakukan proses deserialisasi terhadap setiap instans yang disimpan dan memeriksa isinya. Banyak pengembang lebih suka menulis penyedia persistensi mereka sendiri untuk mengatasi rintangan ini.

Penyedia persistensi WF4 SQL telah mencoba mengatasi beberapa kekhawatiran ini. Tabel persistensi mengekspos informasi tertentu seperti bookmark aktif dan properti yang dapat dipromosikan. Fitur korelasi berbasis konten baru di WF4 tidak akan berkinerja baik menggunakan pendekatan persistensi WF3 SQL, yang telah mendorong beberapa perubahan dalam organisasi instans alur kerja yang bertahan. Ini membuat pekerjaan penyedia persistensi lebih kompleks dan menempatkan stres ekstra pada database.

Penyiapan Lingkungan

Penyetelan Pengujian

Bahkan dengan set fitur yang ditingkatkan dan penanganan konkurensi yang lebih baik, penyedia persistensi SQL di WF4 lebih cepat daripada penyedia di WF3. Untuk menampilkan ini, dua alur kerja yang pada dasarnya melakukan operasi yang sama di WF3 dan WF4 dibandingkan di bawah ini.

Dua alur kerja keduanya dibuat oleh pesan yang diterima. Setelah mengirim balasan awal, alur kerja tetap ada. Dalam kasus WF3, kosong TransactionScopeActivity digunakan untuk memulai persistensi. Hal yang sama dapat dicapai di WF3 dengan menandai aktivitas sebagai "bertahan di dekat." Pesan kedua yang berkorelasi menyelesaikan alur kerja. Alur kerja tetap ada tetapi tidak dibongkar.

Hasil Pengujian

Ketika transportasi antara klien dan tingkat menengah adalah HTTP, persistensi di WF4 menunjukkan peningkatan 2,6 kali. Transportasi TCP meningkatkan faktor tersebut menjadi 3,0 kali lipat. Dalam semua kasus, pemanfaatan CPU pada tingkat tengah adalah 98% atau lebih tinggi. Alasan throughput WF4 lebih besar adalah karena waktu eksekusi alur kerja yang lebih cepat. Ukuran instans yang telah diserialisasi rendah dalam kedua kasus dan bukan elemen yang memberikan kontribusi utama dalam situasi ini.

Alur kerja WF3 dan WF4 dalam pengujian ini menggunakan aktivitas untuk secara eksplisit menunjukkan kapan persistensi harus terjadi. Ini memiliki manfaat mempertahankan alur kerja tanpa membongkarnya. Di WF3, dimungkinkan juga untuk menyimpan menggunakan fitur TimeToUnload, tetapi ini memindahkan instans alur kerja dari memori. Jika pengembang yang menggunakan WF3 ingin memastikan alur kerja tetap ada di titik tertentu, mereka harus mengubah definisi alur kerja atau membayar biaya untuk membongkar dan memuat ulang instans alur kerja. Fitur baru WF4 memungkinkan pemrosesan berkelanjutan tanpa pembongkaran: TimeToPersist. Fitur ini memungkinkan instans alur kerja tetap diam tetapi tetap dalam memori hingga TimeToUnload ambang terpenuhi atau eksekusi dilanjutkan.

Perhatikan bahwa penyedia persistensi WF4 SQL melakukan lebih banyak pekerjaan di tingkat database. Database SQL dapat menjadi hambatan sehingga penting untuk memantau penggunaan CPU dan disk di sana. Pastikan untuk menyertakan penghitung kinerja berikut dari database SQL saat aplikasi alur kerja pengujian performa:

• Waktu Baca PhysicalDisk\%Disk

• PhysicalDisk\% Waktu Disk

• PhysicalDisk\% Waktu Penulisan Disk

• PhysicalDisk\% Rata-rata Panjang Antrean Disk

• PhysicalDisk\Rata-rata Panjang Antrean Baca Disk

• PhysicalDisk\Rata-rata Panjang Antrean Penulisan Disk

• Panjang Antrian Disk Saat Ini

• Informasi Prosesor\% Waktu Prosesor

• SQLServer:Latches\Rata-rata Waktu Tunggu Kait (ms)

• SQLServer:Latches\Latch Waits/detik

Pelacakan

Pelacakan alur kerja dapat digunakan untuk melacak kemajuan alur kerja. Informasi yang disertakan dalam peristiwa pelacakan ditentukan oleh profil pelacakan. Semakin kompleks profil pelacakan, semakin mahal pelacakannya.

WF3 dikirim dengan layanan pelacakan berbasis SQL. Layanan ini dapat berfungsi dalam mode batch dan non-batch. Dalam mode non-batch, peristiwa pelacakan ditulis langsung ke database. Dalam mode batch, peristiwa pelacakan dikumpulkan ke dalam batch yang sama dengan status instans alur kerja. Mode batch memiliki performa terbaik untuk berbagai desain alur kerja terluas. Namun, batching dapat memiliki dampak performa negatif jika alur kerja menjalankan banyak aktivitas tanpa bertahan dan aktivitas tersebut dilacak. Ini biasanya akan terjadi dalam perulangan dan cara terbaik untuk menghindari skenario ini adalah dengan merancang perulangan besar untuk berisi titik persistensi. Memperkenalkan titik persistensi ke dalam perulangan dapat berdampak negatif pada performa juga sehingga penting untuk mengukur biaya masing-masing dan membuat keseimbangan.

WF4 tidak dikirim dengan layanan pelacakan SQL. Merekam informasi pelacakan ke database SQL dapat ditangani dengan lebih baik dari server aplikasi daripada dibangun ke dalam .NET Framework. Oleh karena itu, pelacakan SQL sekarang ditangani oleh AppFabric. Penyedia pelacakan bawaan di WF4 didasarkan pada Pelacakan Peristiwa untuk Windows (ETW).

ETW adalah sistem peristiwa latensi rendah tingkat kernel yang terpasang di Windows. Ini menggunakan model penyedia/konsumen yang memungkinkan untuk hanya dikenakan penalti untuk pelacakan peristiwa ketika sebenarnya ada konsumen. Selain peristiwa kernel seperti prosesor, disk, memori, dan penggunaan jaringan, banyak aplikasi juga memanfaatkan ETW. Peristiwa (event) ETW lebih efektif daripada penghitung kinerja karena peristiwa tersebut bisa disesuaikan untuk aplikasi. Peristiwa dapat berisi teks seperti ID alur kerja atau pesan informasi. Selain itu, peristiwa dikategorikan dengan bitmask sehingga mengkonsumsi subset peristiwa tertentu akan memiliki dampak performa yang lebih sedikit daripada menangkap semua peristiwa.

Manfaat menggunakan ETW untuk pelacakan alih-alih SQL meliputi:

• Kumpulan peristiwa pelacakan dapat dipisahkan ke proses lain. Ini memberikan fleksibilitas yang lebih besar dalam bagaimana peristiwa direkam.

• Peristiwa pelacakan ETW mudah dikombinasikan dengan peristiwa WCF ETW atau penyedia ETW lainnya seperti SQL Server atau penyedia kernel.

• Penulis alur kerja tidak perlu mengubah alur kerja untuk bekerja lebih baik dengan implementasi pelacakan tertentu, seperti mode batch layanan pelacakan WF3 SQL.

• Administrator dapat mengaktifkan atau menonaktifkan pelacakan tanpa mendaur ulang proses host.

Manfaat performa pelacakan ETW dibarengi dengan kelemahan. Peristiwa ETW dapat hilang jika sistem berada di bawah tekanan sumber daya yang intens. Pemrosesan peristiwa tidak dimaksudkan untuk memblokir eksekusi program normal dan oleh karena itu tidak dijamin bahwa semua peristiwa ETW akan disiarkan kepada pelanggan mereka. Ini membuat pelacakan ETW sangat bagus untuk pemantauan kesehatan tetapi tidak cocok untuk audit.

Meskipun WF4 tidak memiliki penyedia pelacakan SQL, AppFabric melakukannya. Pendekatan pelacakan SQL AppFabric adalah berlangganan peristiwa ETW dengan Layanan Windows yang mengumpulkan peristiwa dan menulisnya ke tabel SQL yang dirancang untuk penyisipan cepat. Pekerjaan terpisah menguras data dari tabel ini dan mereformatnya menjadi tabel pelaporan yang dapat dilihat di dasbor AppFabric. Ini berarti bahwa batch peristiwa pelacakan ditangani secara independen dari alur kerja asalnya dan oleh karena itu tidak perlu menunggu titik persistensi sebelum direkam.

Peristiwa ETW dapat direkam dengan alat seperti logman atau xperf. File ETL yang ringkas dapat dilihat dengan alat seperti xperfview atau dikonversi ke format yang lebih dapat dibaca, seperti XML, dengan tracerpt. Di WF3, satu-satunya opsi untuk mendapatkan peristiwa pelacakan tanpa database SQL adalah membuat layanan pelacakan kustom. Untuk informasi selengkapnya tentang ETW, lihat Layanan WCF dan Pelacakan Peristiwa untuk Windows dan Pelacakan Peristiwa - aplikasi Windows.

Mengaktifkan pelacakan alur kerja akan berdampak pada performa dalam berbagai derajat. Tolok ukur di bawah ini menggunakan alat logman untuk mengonsumsi peristiwa pelacakan ETW dan merekamnya dalam file ETL. Biaya pelacakan SQL di AppFabric tidak berada dalam cakupan artikel ini. Profil pelacakan dasar, juga digunakan dalam AppFabric, ditampilkan dalam tolok ukur ini. Juga termasuk biaya pelacakan hanya untuk peristiwa pemantauan kesehatan. Peristiwa ini berguna untuk memecahkan masalah dan menentukan throughput rata-rata sistem.

Penyiapan Lingkungan

Hasil Pengujian

Pemantauan kesehatan berdampak sekitar 3% pada throughput. Biaya untuk profil dasar adalah sekitar 8%.

Interop

WF4 hampir merupakan penulisan ulang WF yang lengkap dan oleh karena itu alur kerja dan aktivitas WF3 tidak kompatibel langsung dengan WF4. Banyak pelanggan yang mengadopsi Windows Workflow Foundation lebih awal akan memiliki definisi alur kerja internal atau pihak ketiga dan aktivitas kustom untuk WF3. Salah satu cara untuk memudahkan transisi ke WF4 adalah dengan menggunakan aktivitas Interop, yang dapat menjalankan aktivitas WF3 dari dalam alur kerja WF4. Disarankan agar Interop aktivitas hanya digunakan jika diperlukan. Untuk informasi selengkapnya tentang migrasi ke WF4, lihat Panduan Migrasi WF4.

Penyiapan Lingkungan

Hasil Pengujian

Tabel berikut ini memperlihatkan hasil menjalankan alur kerja yang berisi lima aktivitas secara berurutan dalam berbagai konfigurasi.

Ujian	Lalu Lintas Data (alur kerja per detik)
Urutan WF3 dalam runtime WF3	1,576
Urutan proses WF3 dalam runtime WF4 menggunakan Interop	2.745
Urutan WF4	153,582

Terdapat peningkatan performa yang signifikan saat menggunakan Interop dibandingkan dengan WF3 tanpa modifikasi. Namun, jika dibandingkan dengan aktivitas WF4, peningkatannya dapat diabaikan.

Ringkasan

Investasi yang berat dalam kinerja untuk WF4 telah membuahkan hasil di banyak bidang penting. Performa komponen alur kerja individu dalam beberapa kasus ratusan kali lebih cepat di WF4 dibandingkan dengan WF3 karena runtime WF yang lebih ramping. Angka latensi juga jauh lebih baik. Ini berarti penalti performa untuk menggunakan WF dibandingkan dengan layanan orkestrasi WCF pengkodean manual sangat kecil dengan mempertimbangkan manfaat tambahan dari penggunaan WF. Performa persistensi meningkat dengan faktor 2,5 - 3,0. Pemantauan kesehatan dengan cara pelacakan alur kerja sekarang memiliki overhead yang sangat sedikit. Serangkaian panduan migrasi yang komprehensif tersedia bagi mereka yang mempertimbangkan untuk berpindah dari WF3 ke WF4. Semua ini harus menjadikan WF4 pilihan yang menarik untuk menulis aplikasi yang kompleks.