Penyedia Azure Storage (Azure Functions)

Dokumen ini menjelaskan karakteristik penyedia Durable Functions Azure Storage, dengan fokus pada aspek performa dan skalabilitas. Penyedia Azure Storage adalah penyedia default. Ia menyimpan antrean dan status instans di akun Azure Storage (klasik).

Catatan

Untuk informasi selengkapnya tentang berbagai opsi penyedia penyimpanan dan bagaimana perbandingannya, lihat dokumentasi penyedia penyimpanan Durable Functions.

Di penyedia Azure Storage, semua eksekusi fungsi didorong oleh antrean Azure Storage. Status dan riwayat orkestrasi serta entitas disimpan dalam Tabel Azure. Azure Blobs dan sewa gumpalan digunakan untuk mendistribusikan instans dan entitas orkestrasi di beberapa instans aplikasi (juga dikenal sebagai pekerja atau hanya VM). Bagian ini menjelaskan lebih rinci tentang berbagai artefak Microsoft Azure Storage dan bagaimana hal itu memengaruhi kinerja dan skalabilitas.

Representasi penyimpanan

Hub tugas mempertahankan semua status instans dan semua pesan. Untuk ringkasan singkat tentang cara hal ini digunakan untuk melacak kemajuan orkestrasi, lihat contoh eksekusi hub tugas.

Penyedia Azure Storage mewakili hub tugas dalam penyimpanan menggunakan komponen berikut:

• Antara dua dan tiga Tabel Azure. Dua tabel digunakan untuk mewakili riwayat dan status instans. Jika Table Partition Manager diaktifkan, maka tabel ketiga diperkenalkan untuk menyimpan informasi partisi.
• Satu Azure Queue menyimpan pesan aktivitas.
• Satu atau beberapa Azure Queue menyimpan pesan instans. Setiap antrean kontrol ini mewakili partisi dengan subset dari semua pesan instans berdasarkan hash ID instans yang ditetapkan.
• Beberapa kontainer blob tambahan yang digunakan untuk menyewa blob dan/atau pesan berukuran besar.

Sebagai contohnya, hub tugas bernama xyz dengan PartitionCount = 4 berisi antrean dan tabel berikut:

Selanjutnya, kami menjelaskan komponen ini dan peran yang mereka mainkan secara lebih rinci.

Tabel riwayat

Tabel Riwayat adalah tabel Azure Storage yang berisi peristiwa riwayat untuk semua instans orkestrasi dalam hub tugas. Nama tabel ini ada dalam bentuk Riwayat TaskHubName. Saat instans berjalan, baris baru ditambahkan ke tabel ini. Kunci partisi tabel ini berasal dari ID instans orkestrasi. ID instans acak secara default, memastikan distribusi partisi internal yang optimal di Microsoft Azure Storage. Kunci baris untuk tabel ini adalah nomor urutan yang digunakan untuk memesan peristiwa riwayat.

Saat instance orkestrasi perlu dijalankan, baris terkait dari tabel Riwayat dimuat ke dalam memori menggunakan kueri rentang dalam satu partisi tabel. Peristiwa riwayat ini kemudian diputar ulang ke dalam kode fungsi orkestrator untuk mendapatkannya kembali ke status yang sebelumnya di pos pemeriksaan. Penggunaan riwayat eksekusi untuk membangun kembali status dengan cara ini dipengaruhi oleh pola Sumber Peristiwa.

Tip

Data orkestrasi yang disimpan dalam tabel Riwayat mencakup muatan output dari fungsi aktivitas dan sub-orkestrator. Muatan dari acara eksternal juga disimpan dalam tabel Riwayat. Karena sejarah penuh dimuat ke dalam memori setiap kali orkestrator perlu mengeksekusi, sejarah yang cukup besar dapat menghasilkan tekanan memori yang signifikan pada VM tertentu. Panjang dan ukuran riwayat orkestrasi dapat dikurangi dengan membagi orkestrasi besar menjadi beberapa sub-orkestrasi atau dengan mengurangi ukuran output yang dikembalikan oleh aktivitas dan fungsi sub-orkestrator yang disebutnya. Atau, Anda dapat mengurangi penggunaan memori dengan menurunkan throttle konkurensi per-VM untuk membatasi berapa banyak orkestrasi yang dimuat ke dalam memori secara bersamaan.

Tabel instans

Tabel Instans adalah tabel Azure Storage lain yang berisi status semua orkestrasi dan instans entitas dalam hub tugas. Saat instans dibuat, baris baru ditambahkan ke tabel ini. Kunci partisi tabel ini adalah ID instans orkestrasi atau kunci entitas dan kunci baris adalah string kosong. Ada satu baris per orkestrasi atau instans entitas.

Tabel ini digunakan untuk memenuhi permintaan kueri instans dari kode serta panggilan API HTTP kueri status. Pada akhirnya ini dijaga konsisten dengan isi tabel Riwayat yang disebutkan sebelumnya. Penggunaan tabel Azure Storage terpisah untuk secara efisien memenuhi operasi kueri instans dengan cara ini dipengaruhi oleh pola Command and Query Responsibility Segregation (CQRS).

Tip

Partisi tabel Instans memungkinkan untuk menyimpan jutaan instance orkestrasi tanpa dampak nyata pada kinerja atau skala runtime. Namun, jumlah instans dapat berdampak signifikan pada kinerja kueri multi-instans. Untuk mengontrol jumlah data yang disimpan dalam tabel ini, pertimbangkan untuk membersihkan data instans lama secara berkala.

Tabel partisi

Catatan

Tabel ini ditampilkan di hub tugas hanya ketika Table Partition Manager diaktifkan. Untuk menerapkannya, konfigurasikan useTablePartitionManagement pengaturan di host.json aplikasi Anda.

Tabel Partisi menyimpan status partisi untuk aplikasi Durable Functions dan digunakan untuk mendistribusikan partisi di seluruh pekerja aplikasi Anda. Ada satu baris per partisi.

Antrean

Baik fungsi orkestrator dan fungsi aktivitas dipicu oleh antrean internal di hub tugas aplikasi fungsi. Menggunakan antrean dengan cara ini memberikan jaminan pengiriman pesan "setidaknya sekali" yang andal. Ada dua jenis antrean dalam Durable Functions: antrean kontrol dan antrean item kerja.

Antrean item kerja

Ada satu antrean item kerja per hub tugas di Durable Functions. Ini adalah antrean dasar dan berperilaku mirip dengan antrean queueTrigger lain di Azure Functions. Antrean ini digunakan untuk memicu fungsi aktivitas stateless dengan mengurai antrean satu pesan pada satu waktu. Tiap pesan ini berisi input fungsi aktivitas dan metadata tambahan, seperti fungsi mana yang akan dijalankan. Ketika aplikasi Durable Functions diskalakan ke beberapa VM, VM ini semuanya bersaing untuk memperoleh pekerjaan dari antrean item kerja.

Antrean Kontrol

Ada beberapa antrean kontrol per hub tugas di Durable Functions. Antrean kontrol lebih canggih daripada antrean item kerja yang lebih sederhana. Antrean kontrol digunakan untuk memicu fungsi orkestra dan entitas yang stateful. Karena instans fungsi orkestrator dan entitas adalah database tunggal yang stateful, penting bahwa tiap orkestrasi atau entitas hanya diproses oleh satu pekerja pada satu waktu. Untuk mencapai hal ini, tiap instans atau entitas orkestrasi ditetapkan ke satu antrean kontrol. Antrean kontrol ini seimbang di seluruh pekerja untuk memastikan bahwa setiap antrean hanya diproses oleh satu pekerja pada satu waktu. Detail lebih lanjut tentang perilaku ini dapat ditemukan di bagian berikutnya.

Antrean kontrol berisi berbagai jenis pesan siklus hidup orkestrasi. Contohnya termasuk pesan kontrol orkestrator, pesan respons fungsi aktivitas, dan pesan timer. Sebanyak 32 pesan akan dilepas dari antrean kontrol dalam satu polling. Pesan-pesan ini berisi data payload serta metadata termasuk instans orkestrasi mana yang dimaksudkan untuknya. Jika beberapa pesan yang dikeluarkan dari antrean ditujukan untuk instance orkestrasi yang sama, pesan tersebut akan diproses sebagai batch.

Pesan antrean kontrol terus dijajaki menggunakan utas latar belakang. Ukuran batch setiap jajak pendapat antrean dikendalikan oleh controlQueueBatchSize pengaturan di host.jsaktif dan memiliki default 32 (nilai maksimum yang didukung oleh Azure Queues). Jumlah maksimum pesan antrean kontrol yang telah ada sebelumnya yang di-buffer dalam memori dikontrol oleh controlQueueBufferThreshold pengaturan host.json. Nilai default untuk controlQueueBufferThreshold bervariasi tergantung pada berbagai faktor, termasuk jenis paket hosting. Untuk informasi selengkapnya tentang pengaturan ini, lihat dokumentasi skema host.json.

Tip

Meningkatkan nilai untuk controlQueueBufferThreshold memungkinkan satu orkestrasi atau entitas untuk memproses peristiwa lebih cepat. Namun, meningkatkan nilai ini juga dapat mengakibatkan penggunaan memori yang lebih tinggi. Penggunaan memori yang lebih tinggi sebagian disebabkan oleh menarik lebih banyak pesan dari antrean dan sebagian karena mengambil lebih banyak riwayat orkestrasi ke dalam memori. Oleh karena itu, mengurangi nilai controlQueueBufferThreshold dapat menjadi cara yang efektif untuk mengurangi penggunaan memori.

Polling antrean

Ekstensi tugas yang tahan lama mengimplementasikan algoritma back-off eksponensial acak untuk mengurangi efek polling antrean diam pada biaya transaksi penyimpanan. Saat pesan ditemukan, runtime segera memeriksa pesan lain. Ketika tidak ada pesan yang ditemukan, pesan menunggu jangka waktu tertentu sebelum mencoba lagi. Setelah upaya gagal berikutnya untuk mendapatkan pesan antrean, waktu tunggu terus meningkat sampai mencapai waktu tunggu maksimum default, yaitu 30 detik.

Waktu tunggu maksimum dapat dikonfigurasi melalui properti maxQueuePollingInterval di file host.json. Menyetel properti ini ke nilai yang lebih tinggi dapat mengakibatkan latensi pemrosesan pesan yang lebih tinggi. Latensi yang lebih tinggi akan diharapkan hanya setelah periode tidak aktif. Menetapkan properti ini ke nilai yang lebih rendah dapat mengakibatkan biaya penyimpanan yang lebih tinggi karena peningkatan transaksi penyimpanan.

Catatan

Saat berjalan dalam paket Azure Functions Consumption dan Premium, Azure Functions Scale Controller akan melakukan polling setiap kontrol dan antrean item kerja setiap 10 detik sekali. Polling tambahan ini diperlukan untuk menentukan kapan mengaktifkan instans aplikasi fungsi dan membuat keputusan skala. Pada saat ditulis, interval 10 detik ini konstan dan tidak dapat dikonfigurasi.

Penundaan mulai orkestrasi

Instans orkestrasi dimulai dengan meletakkan pesan ExecutionStarted di salah satu antrean kontrol hub tugas. Dalam kondisi tertentu, Anda dapat mengamati penundaan multi-detik antara ketika orkestrasi dijadwalkan berjalan dan kapan orkestrasi benar-benar mulai berjalan. Selama interval waktu ini, instans orkestrasi tetap berada di status Pending. Ada dua kemungkinan penyebab penundaan ini:

• Antrean kontrol backlog: Jika antrean kontrol untuk instans ini berisi sejumlah besar pesan, mungkin perlu waktu sebelum pesan ExecutionStarted diterima dan diproses oleh runtime. Backlog pesan dapat terjadi ketika orkestrasi memproses banyak peristiwa secara bersamaan. Peristiwa yang masuk ke antrean kontrol termasuk peristiwa permulaan orkestrasi, penyelesaian aktivitas, timer tahan lama, penghentian, dan peristiwa eksternal. Jika penundaan ini terjadi dalam keadaan normal, pertimbangkan untuk membuat hub tugas baru dengan jumlah partisi yang lebih besar. Mengonfigurasi lebih banyak partisi akan menyebabkan runtime membuat lebih banyak antrean kontrol untuk distribusi beban. Setiap partisi sesuai 1:1 dengan antrean kontrol, dengan maksimum 16 partisi.

• Penundaan polling back-off: Penyebab umum penundaan orkestrasi lainnya adalah perilaku polling back-off yang dijelaskan sebelumnya untuk antrean kontrol. Namun, penundaan ini hanya diharapkan ketika aplikasi diskalakan ke dua instans atau lebih. Jika hanya ada satu instans aplikasi atau jika instans aplikasi yang memulai orkestrasi juga merupakan instans yang sama yang melakukan polling antrean kontrol target, tidak akan ada penundaan polling antrean. Penundaan polling back-off dapat dikurangi dengan memperbarui pengaturan host.json, seperti yang dijelaskan sebelumnya.

Blob

Dalam kebanyakan kasus, Durable Functions tidak menggunakan Azure Storage Blobs untuk menjaga data. Namun, antrean dan tabel memiliki batas ukuran yang dapat mencegah Durable Functions dari bertahan semua data yang diperlukan ke dalam baris penyimpanan atau pesan antrean. Misalnya, ketika sepotong data yang perlu digiatkan ke antrean lebih besar dari 45 KB saat diserialisasikan, Durable Functions akan memadatkan data dan menyimpannya dalam blob sebagai gantinya. Saat menyimpan data persistensi ke penyimpanan blob dengan cara ini, Durable Function menyimpan referensi ke blob tersebut di baris tabel atau pesan antrean. Ketika Durable Functions perlu mengambil data itu akan secara otomatis mengambilnya dari blob. Blob ini disimpan dalam kontainer blob <taskhub>-largemessages.

Pertimbangan performa

Langkah-langkah operasi pemadatan dan blob ekstra untuk pesan besar bisa mahal dalam hal biaya latensi CPU dan I/O. Selain itu, Durable Functions perlu memuat data yang bertahan dalam memori, dan dapat melakukannya untuk banyak eksekusi fungsi yang berbeda pada saat yang sama. Akibatnya, payload data besar yang terus-menerus dapat menyebabkan penggunaan memori yang tinggi juga. Untuk meminimalkan overhead memori, pertimbangkan untuk terus melakukan payload data besar secara manual (misalnya, dalam penyimpanan blob) dan sebaliknya meneruskan referensi ke data ini. Dengan cara ini kode Anda dapat memuat data hanya ketika diperlukan untuk menghindari beban berlebihan selama pemutaran ulang fungsi orkestrator. Namun, menyimpan payload ke disk lokal tidak direkomendasikan karena status on-disk tidak dijamin tersedia karena fungsi dapat dijalankan pada mesin virtual yang berbeda selama masa pakainya.

Pilihan akun penyimpanan

Antrean, tabel, dan blob yang digunakan oleh Durable Functions dibuat dalam akun Azure Storage yang dikonfigurasi. Akun yang akan digunakan dapat ditentukan menggunakan pengaturan durableTask/storageProvider/connectionStringName (atau pengaturan durableTask/azureStorageConnectionStringName di Durable Functions 1.x) dalam file host.json.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

Jika tidak ditentukan, akun penyimpanan AzureWebJobsStorage default digunakan. Namun, untuk beban kerja yang sensitif terhadap performa, mengonfigurasi akun penyimpanan non-default disarankan. Durable Functions sangat menggunakan Azure Storage, dan menggunakan akun penyimpanan khusus mengisolasi penggunaan penyimpanan Durable Functions dari penggunaan internal oleh host Azure Functions.

Catatan

Akun Microsoft Azure Storage tujuan umum standar diperlukan saat menggunakan penyedia Microsoft Azure Storage. Semua jenis akun penyimpanan lainnya tidak didukung. Kami sangat menyarankan penggunaan akun penyimpanan tujuan umum legacy v1 untuk Durable Functions. Akun penyimpanan v2 yang lebih baru dapat secara signifikan lebih mahal untuk beban kerja Durable Functions. Untuk mengetahui informasi selengkapnya tentang jenis akun Microsoft Azure Storage, lihat dokumentasi Gambaran umum akun penyimpanan.

Penskalaan orkestrator

Sementara fungsi aktivitas dapat diskalakan tanpa batas dengan menambahkan lebih banyak VM secara elastis, instans dan entitas orkestrator individu dibatasi untuk menghuni partisi tunggal dan jumlah maksimum partisi dibatasi oleh pengaturan partitionCount di host.json Anda.

Catatan

Secara umum, fungsi orkestrator dimaksudkan agar ringan dan seharusnya tidak memerlukan daya komputasi dalam jumlah besar. Oleh karena itu tidak perlu membuat sejumlah besar partisi antrean kontrol untuk mendapatkan throughput yang bagus untuk orkestrasi. Sebagian besar pekerjaan berat harus dilakukan dalam fungsi aktivitas tanpa status, yang dapat diskalakan tanpa batas.

Jumlah antrean kontrol didefinisikan dalam file host.json. Cuplikan host.json contoh berikut mengatur properti durableTask/storageProvider/partitionCount (atau durableTask/partitionCount dalam Durable Functions 1.x) ke 3. Perhatikan bahwa ada banyak antrean kontrol karena ada partisi.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "partitionCount": 3
    }
  }
}

Hub tugas dapat dikonfigurasi antara 1 dan 16 partisi. Jika tidak ditentukan, jumlah partisi default adalah 4.

Selama skenario lalu lintas rendah, aplikasi Anda akan diskalakan, sehingga partisi akan dikelola oleh sejumlah kecil pekerja. Sebagai contoh, perhatikan diagram di bawah ini.

Dalam diagram sebelumnya, kita melihat bahwa orkestrator 1 sampai 6 adalah seimbang di seluruh partisi. Demikian pula, partisi, seperti kegiatan, seimbang di seluruh pekerja. Partisi seimbang di seluruh pekerja terlepas dari jumlah orkestrator yang memulai.

Jika Anda menjalankan paket Azure Functions Consumption atau Elastic Premium, atau jika Anda memiliki auto-scaling berbasis beban yang dikonfigurasi, lebih banyak pekerja akan dialokasikan karena peningkatan lalu lintas dan partisi pada akhirnya akan memuat keseimbangan di semua pekerja. Jika kita terus menskalakan, akhirnya setiap partisi pada akhirnya akan dikelola oleh satu pekerja. Aktivitas, di sisi lain, akan terus seimbang di semua pekerja. Ini ditunjukkan pada gambar di bawah ini.

Batas atas jumlah maksimum orkestrasi aktif bersamaan pada waktu tertentu sama dengan jumlah pekerja yang dialokasikan untuk aplikasi Anda kali nilai Anda untuk maxConcurrentOrchestratorFunctions. Batas atas ini dapat dibuat lebih tepat ketika partisi Anda sepenuhnya diskalakan di seluruh pekerja. Ketika sepenuhnya diskalakan, dan karena setiap pekerja hanya akan memiliki satu instans host Functions, jumlah maksimum instans orkestrator bersamaan aktif akan sama dengan jumlah partisi Anda kali nilai Anda untuk maxConcurrentOrchestratorFunctions.

Catatan

Dalam konteks ini, aktif berarti bahwa orkestrasi atau entitas dimuat ke dalam memori dan memproses peristiwa baru. Jika orkestrasi atau entitas menunggu lebih banyak peristiwa, seperti nilai pengembalian fungsi aktivitas, itu akan dibongkar dari memori dan tidak lagi dianggap aktif. Orkestrasi dan entitas kemudian akan dimuat ulang ke dalam memori hanya ketika ada peristiwa baru untuk diproses. Tidak ada jumlah maksimum praktis dari total orkestrasi atau entitas yang dapat berjalan pada satu VM, bahkan jika mereka semua dalam keadaan "Berjalan". Satu-satunya batasan adalah jumlah orkestrasi atau instans entitas aktif bersamaan.

Gambar kami di bawah ini menggambarkan skenario yang sepenuhnya diskalakan di mana lebih banyak orkestrator ditambahkan tetapi beberapa tidak aktif, ditunjukkan dalam warna abu-abu.

Selama penskalaan, kunci antrean kontrol dapat didistribusikan ulang di seluruh instans host Fungsi untuk memastikan bahwa partisi didistribusikan secara merata. Penyewaan ini diimplementasikan secara internal sebagai sewa penyimpanan Azure Blob dan memastikan bahwa setiap instans atau entitas orkestrasi individu hanya berjalan pada satu instans host pada satu waktu. Jika hub tugas dikonfigurasi dengan tiga partisi (dan oleh karena itu tiga antrean kontrol), instans dan entitas orkestrasi dapat diseimbangkan dengan beban di ketiga instans host yang memegang sewa. VM tambahan dapat ditambahkan untuk meningkatkan kapasitas untuk pelaksanaan fungsi aktivitas.

Diagram berikut ini menggambarkan bagaimana host Azure Functions berinteraksi dengan entitas penyimpanan dalam lingkungan yang diskalakan.

Seperti yang ditunjukkan pada diagram sebelumnya, semua VM bersaing untuk mendapatkan pesan pada antrean item kerja. Namun, hanya tiga VM yang dapat memperoleh pesan dari antrean kontrol, dan setiap VM mengunci satu antrean kontrol.

Instans dan entitas orkestrasi didistribusikan di semua instans antrean kontrol. Distribusi dilakukan dengan hashing ID instans orkestrasi atau nama entitas dan pasangan kunci. ID instans orkestrasi secara default adalah GUID acak, yang memastikan bahwa instans didistribusikan secara merata di semua antrean kontrol.

Secara umum, fungsi orkestrator dimaksudkan agar ringan dan seharusnya tidak memerlukan daya komputasi dalam jumlah besar. Oleh karena itu tidak perlu membuat sejumlah besar partisi antrean kontrol untuk mendapatkan throughput yang bagus untuk orkestrasi. Sebagian besar pekerjaan berat harus dilakukan dalam fungsi aktivitas tanpa status, yang dapat diskalakan tanpa batas.

Sesi yang diperpanjang

Sesi yang diperpanjang adalah mekanisme penembolokan yang menjaga orkestrasi dan entitas dalam memori bahkan setelah mereka selesai memproses pesan. Efek khas dari mengaktifkan sesi yang diperpanjang adalah berkurangnya I/O terhadap penyimpanan tahan lama dan throughput yang meningkat secara keseluruhan.

Anda dapat mengaktifkan sesi yang diperluas dengan mengatur durableTask/extendedSessionsEnabled ke true dalam file host.json. Pengaturan durableTask/extendedSessionIdleTimeoutInSecondsdapat digunakan untuk mengontrol berapa lama sesi diam akan ditahan dalam memori:

Functions 2.0

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Functions 1.0

{
  "durableTask": {
    "extendedSessionsEnabled": true,
    "extendedSessionIdleTimeoutInSeconds": 30
  }
}

Ada dua potensi kelemahan pada pengaturan ini yang perlu diperhatikan:

1. Ada peningkatan keseluruhan dalam penggunaan memori aplikasi fungsi karena instans menganggur tidak dibongkar dari memori secepat mungkin.
2. Dapat terjadi penurunan throughput secara keseluruhan jika ada banyak eksekusi fungsi orkestrator atau entitas berumur pendek secara bersamaan.

Sebagai contoh, jika durableTask/extendedSessionIdleTimeoutInSeconds diatur ke 30 detik, episode fungsi orkestrator atau entitas berumur pendek yang mengeksekusi dalam waktu kurang dari 1 detik masih menempati memori selama 30 detik. Ini juga dihitung terhadap kuota durableTask/maxConcurrentOrchestratorFunctions yang disebutkan sebelumnya, yang berpotensi mencegah fungsi orkestrator atau entitas lain berjalan.

Efek spesifik dari sesi yang diperpanjang pada fungsi orkestrator dan entitas dijelaskan di bagian berikutnya.

Catatan

Sesi yang diperpanjang saat ini hanya didukung dalam bahasa .NET, seperti C# atau F#. Pengaturan extendedSessionsEnabled sampai true untuk platform lain dapat menyebabkan masalah runtime, seperti diam-diam gagal menjalankan aktivitas dan fungsi yang dipicu orkestrasi.

Putar ulang fungsi orkestrator

Seperti disebutkan sebelumnya, fungsi orkestrator diputar ulang menggunakan konten tabel Riwayat. Secara default, kode fungsi orkestrator diputar ulang setiap kali batch pesan dilepas dari antrean kontrol. Bahkan jika Anda menggunakan pola fan-out, fan-in, dan sedang menunggu semua tugas selesai (misalnya, menggunakan Task.WhenAll() di .NET, context.df.Task.all() di JavaScript, atau context.task_all() di Python), akan ada pemutaran ulang yang terjadi saat batch respons tugas diproses dari waktu ke waktu. Ketika sesi yang diperpanjang diaktifkan, instans fungsi orkestrator ditahan di memori lebih lama dan pesan baru dapat diproses tanpa pemutaran ulang riwayat penuh.

Peningkatan performa sesi yang diperpanjang paling sering diamati dalam situasi berikut:

• Ketika ada instans orkestrasi dalam jumlah terbatas yang berjalan bersamaan.
• Ketika orkestrasi memiliki sejumlah besar tindakan berurutan (misalnya ratusan panggilan fungsi aktivitas) yang selesai dengan cepat.
• Ketika orkestrasi melakukan fan-out dan fan-in sejumlah besar tindakan yang selesai sekitar waktu yang sama.
• Ketika fungsi orkestrator perlu memproses pesan besar atau melakukan pemrosesan data yang intensif CPU.

Dalam semua situasi lain, biasanya tidak ada peningkatan performa yang dapat diamati untuk fungsi orkestrator.

Catatan

Pengaturan ini hanya boleh digunakan setelah fungsi orkestrator telah sepenuhnya dikembangkan dan diuji. Perilaku pemutaran ulang agresif default dapat berguna untuk mendeteksi pelanggaran batasan kode fungsi orkestrator pada waktu pengembangan, dan karenanya dinonaktifkan secara default.

Target performa

Tabel berikut ini menunjukkan angka throughput maksimum yang diharapkan untuk skenario yang dijelaskan di bagian Target Performa di artikel Performa dan Skala.

"Instans" mengacu pada satu instans fungsi orkestrator yang berjalan pada VM kecil (A1) tunggal di Azure App Service. Dalam semua kasus, diasumsikan bahwa sesi yang diperpanjang diaktifkan. Hasil aktual dapat bervariasi tergantung pada pekerjaan CPU atau I/O yang dilakukan oleh kode fungsi.

Skenario	Throughput maksimum
Eksekusi aktivitas berurutan	5 aktivitas per detik, per instans
Eksekusi aktivitas paralel (fan-out)	100 aktivitas per detik, per instans
Pemrosesan respons paralel (fan-in)	150 respons per detik, per instans
Pemrosesan peristiwa eksternal	50 peristiwa per detik, per instans
Pemrosesan operasi entitas	64 operasi per detik

Jika Anda tidak melihat nomor throughput yang Anda harapkan dan penggunaan CPU dan memori Anda tampak sehat, periksa apakah penyebabnya terkait dengan kesehatan akun penyimpanan Anda. Ekstensi Durable Functions dapat memuat secara signifikan pada akun Azure Storage dan beban yang cukup tinggi dapat mengakibatkan pembatasan akun penyimpanan.

Tip

Dalam beberapa kasus, Anda dapat secara signifikan meningkatkan throughput peristiwa eksternal, aktivitas fan-in, dan operasi entitas dengan meningkatkan nilai pengaturan controlQueueBufferThreshold dalam host.json. Meningkatkan nilai ini di luar defaultnya menyebabkan penyedia penyimpanan Kerangka Kerja Tugas Tahan Lama menggunakan lebih banyak memori untuk melakukan prefetch peristiwa ini secara lebih agresif, mengurangi penundaan yang terkait dengan penghapusan pesan dari antrean kontrol Microsoft Azure Storage. Untuk mengetahui informasi selengkapnya, lihat dokumen referensi host.json.

Pemrosesan throughput tinggi

Arsitektur backend Microsoft Azure Storage menempatkan batasan tertentu pada kinerja teoritis maksimum dan skalabilitas Durable Functions. Jika pengujian Anda menunjukkan bahwa Durable Functions pada Microsoft Azure Storage tidak akan memenuhi persyaratan throughput, Anda harus mempertimbangkan sebagai gantinya menggunakan penyedia penyimpanan Netherite untuk Durable Functions.

Guna membandingkan throughput yang dapat dicapai untuk berbagai skenario dasar, lihat bagian Skenario Dasar dari dokumentasi penyedia penyimpanan Netherite.

Backend penyimpanan Netherite dirancang dan dikembangkan oleh Microsoft Research. Ini menggunakan Azure Event Hubsdan teknologi database FASTER di atas Azure Page Blobs. Desain Netherite memungkinkan pemrosesan orkestrasi dan entitas dengan throughput yang jauh lebih tinggi dibandingkan dengan penyedia lain. Dalam beberapa skenario tolok ukur, throughput terbukti meningkat lebih dari urutan besarnya jika dibandingkan dengan penyedia Azure Storage default.

Untuk informasi selengkapnya tentang berbagai opsi penyedia penyimpanan dan bagaimana perbandingannya, lihat dokumentasi penyedia penyimpanan Durable Functions.

Langkah berikutnya

Pelajari pemulihan bencana dan distribusi geografis