Panduan performa dan skala untuk Azure Event Hubs dan Azure Functions

Azure Event Hubs
Azure Functions

Artikel ini menyediakan panduan untuk mengoptimalkan skalabilitas dan performa saat Anda menggunakan Azure Event Hubs dan Azure Functions bersama-sama dalam aplikasi Anda.

Pengelompokan fungsi

Biasanya, fungsi merangkum unit kerja dalam aliran pemrosesan peristiwa. Misalnya, fungsi dapat mengubah peristiwa menjadi struktur data baru atau memperkaya data untuk aplikasi hilir.

Di Functions, aplikasi fungsi menyediakan konteks eksekusi untuk fungsi. Perilaku aplikasi fungsi berlaku untuk semua fungsi yang dihosting aplikasi fungsi. Fungsi dalam aplikasi fungsi disebarkan bersama-sama dan diskalakan bersama-sama. Semua fungsi dalam aplikasi fungsi harus menggunakan bahasa yang sama.

Cara Anda mengelompokkan fungsi ke dalam aplikasi fungsi dapat memengaruhi kemampuan performa dan penskalaan aplikasi fungsi Anda. Anda dapat mengelompokkan sesuai dengan hak akses, penyebaran, dan pola penggunaan yang memanggil kode Anda.

Untuk panduan tentang praktik terbaik Functions untuk pengelompokan dan aspek lainnya, lihat Praktik terbaik untuk Azure Functions yang andal dan Meningkatkan performa dan keandalan Azure Functions.

Daftar berikut adalah panduan untuk mengelompokkan fungsi. Panduan ini mempertimbangkan aspek penyimpanan dan grup konsumen:

  • Host satu fungsi dalam aplikasi fungsi: Jika Azure Event Hubs memicu fungsi, Anda dapat, untuk mengurangi pertikaian antara fungsi tersebut dan fungsi lain, isolasi fungsi di aplikasi fungsinya sendiri. Isolasi sangat penting jika fungsi lain adalah CPU atau memori intensif. Teknik ini membantu karena setiap fungsi memiliki jejak memori dan pola penggunaannya sendiri yang dapat secara langsung memengaruhi penskalaan aplikasi fungsi yang menghostingnya.

  • Beri setiap aplikasi fungsi akun penyimpanannya sendiri: Hindari berbagi akun penyimpanan antar aplikasi fungsi. Selain itu, jika aplikasi fungsi menggunakan akun penyimpanan, jangan gunakan akun tersebut untuk operasi atau kebutuhan penyimpanan lainnya. Sangat penting untuk menghindari berbagi akun penyimpanan untuk fungsi yang dipicu Azure Event Hubs, karena fungsi tersebut dapat memiliki volume transaksi penyimpanan yang tinggi karena titik pemeriksaan.

  • Membuat grup konsumen khusus untuk setiap aplikasi fungsi: Grup konsumen adalah tampilan pusat aktivitas. Grup konsumen yang berbeda memiliki tampilan yang berbeda, yang berarti bahwa status, posisi, dan offset dapat berbeda. Grup konsumen memungkinkan beberapa aplikasi yang menggunakan untuk memiliki pandangan mereka sendiri tentang aliran peristiwa, dan membaca aliran secara independen dengan kecepatan mereka sendiri dan dengan offset mereka sendiri. Untuk informasi selengkapnya tentang grup konsumen, lihat Fitur dan terminologi di Azure Event Hubs.

    Grup konsumen memiliki satu atau beberapa aplikasi konsumen yang terkait dengannya, dan aplikasi konsumen dapat menggunakan satu atau beberapa grup konsumen. Dalam solusi pemrosesan aliran, setiap aplikasi konsumen sama dengan grup konsumen. Aplikasi fungsi adalah contoh utama dari aplikasi konsumen. Diagram berikut menyediakan contoh dua aplikasi fungsi yang dibaca dari pusat aktivitas, di mana setiap aplikasi memiliki grup konsumen khususnya sendiri:

    Grup konsumen khusus untuk setiap aplikasi fungsi

    Jangan berbagi grup konsumen antara aplikasi fungsi dan aplikasi konsumen lainnya. Setiap aplikasi fungsi harus menjadi aplikasi yang berbeda dengan grup konsumen yang ditetapkan sendiri untuk memastikan integritas offset untuk setiap konsumen dan untuk menyederhanakan dependensi dalam arsitektur streaming peristiwa. Konfigurasi seperti itu, bersama dengan menyediakan setiap fungsi yang dipicu hub peristiwa aplikasi fungsi dan akun penyimpanannya sendiri, membantu mengatur fondasi untuk performa dan penskalaan yang optimal.

Paket hosting fungsi

Ada beberapa opsi hosting untuk aplikasi fungsi dan penting untuk meninjau kemampuannya. Untuk informasi tentang opsi hosting ini, lihat Opsi hosting Azure Functions. Perhatikan bagaimana opsi diskalakan.

Paket Konsumsi adalah default. Aplikasi fungsi dalam skala paket Konsumsi secara independen dan paling efektif saat menghindari tugas yang berjalan lama.

Paket Premium dan Khusus sering digunakan untuk menghosting beberapa aplikasi fungsi dan fungsi yang lebih intensif CPU dan memori. Dengan paket Khusus, Anda menjalankan fungsi Anda dalam paket Azure App Service dengan tarif paket App Service reguler. Penting untuk dicatat bahwa semua aplikasi fungsi dalam paket ini berbagi sumber daya yang dialokasikan ke paket. Jika fungsi memiliki profil beban yang berbeda atau persyaratan unik, yang terbaik adalah menghostingnya dalam paket yang berbeda, terutama dalam aplikasi pemrosesan aliran.

Azure Container Apps menyediakan dukungan terintegrasi untuk mengembangkan, menyebarkan, dan mengelola aplikasi fungsi dalam kontainer di Azure Functions. Ini memungkinkan Anda menjalankan fungsi berbasis peristiwa di lingkungan berbasis Kubernetes yang dikelola sepenuhnya dengan dukungan bawaan untuk pemantauan sumber terbuka, mTLS, Dapr, dan KEDA.

Penskalaan Event Hubs

Saat Anda menyebarkan namespace Layanan Pusat Aktivitas, ada beberapa pengaturan penting yang perlu Anda atur dengan benar untuk memastikan performa puncak dan penskalaan. Bagian ini berfokus pada tingkat Standar Azure Event Hubs dan fitur unik dari tingkat tersebut yang memengaruhi penskalaan saat Anda juga menggunakan Functions. Untuk informasi selengkapnya tentang tingkat Event Hubs, lihat Tingkat dasar vs. Standar vs. Premium vs. Khusus.

Namespace Layanan Azure Event Hubs sesuai dengan kluster Kafka. Untuk informasi tentang bagaimana Azure Event Hubs dan Kafka berhubungan satu dengan yang lain, lihat Apa itu Azure Event Hubs untuk Apache Kafka.

Memahami unit throughput (TU)

Di tingkat Azure Event Hubs Standard, throughput diklasifikasikan sebagai jumlah data yang masuk dan dibaca dari namespace per unit waktu. TU adalah unit kapasitas throughput yang telah dibeli sebelumnya.

TU ditagih per jam.

Semua hub peristiwa di namespace layanan berbagi TU. Untuk menghitung kebutuhan kapasitas dengan benar, Anda harus mempertimbangkan semua aplikasi dan layanan, baik penerbit maupun konsumen. Fungsi memengaruhi jumlah byte dan peristiwa yang diterbitkan ke dan dibaca dari pusat aktivitas.

Penekanan untuk menentukan jumlah TU ada pada titik masuk. Namun, agregat untuk aplikasi konsumen, termasuk tingkat di mana peristiwa tersebut diproses, juga harus dimasukkan dalam perhitungan.

Untuk informasi selengkapnya tentang unit throughput Azure Event Hubs, lihat Unit throughput.

Meningkatkan skala dengan Peningkatan otomatis

Inflate otomatis dapat diaktifkan pada namespace Layanan Pusat Aktivitas untuk mengakomodasi situasi di mana beban melebihi jumlah TU yang dikonfigurasi. Menggunakan Auto-inflate mencegah pembatasan aplikasi Anda dan membantu memastikan bahwa pemrosesan, termasuk penyerapan peristiwa, berlanjut tanpa gangguan. Karena pengaturan TU memengaruhi biaya, menggunakan Auto-inflate membantu mengatasi kekhawatiran tentang provisi berlebih.

Auto-inflate adalah fitur Event Hubs yang sering dikacaukan dengan skala otomatis, terutama dalam konteks solusi tanpa server. Namun, Auto-inflate, tidak seperti skala otomatis, tidak menurunkan skala ketika kapasitas tambahan tidak lagi diperlukan.

Jika aplikasi membutuhkan kapasitas yang melebihi jumlah MAKSIMUM TU yang diizinkan, pertimbangkan untuk menggunakan tingkat Event Hubs Premium atau tingkat Khusus.

Partisi dan fungsi bersamaan

Saat hub peristiwa dibuat, jumlah partisi harus ditentukan. Jumlah partisi tetap dan tidak dapat diubah kecuali dari tingkat Premium dan Khusus. Saat Azure Event Hubs memicu aplikasi fungsi, ada kemungkinan jumlah instans bersamaan dapat sama dengan jumlah partisi.

Dalam paket hosting Konsumsi dan Premium, instans aplikasi fungsi menskalakan secara dinamis untuk memenuhi jumlah partisi, jika diperlukan. Paket Hosting khusus menjalankan fungsi dalam paket App Service dan mengharuskan Anda mengonfigurasi instans Anda secara manual atau menyiapkan skema skala otomatis. Untuk informasi selengkapnya, lihat Paket hosting khusus untuk Azure Functions.

Pada akhirnya, hubungan satu-ke-satu antara jumlah partisi dan instans fungsi, atau konsumen, adalah target ideal untuk throughput maksimum dalam solusi pemrosesan aliran. Untuk mencapai paralelisme yang optimal, memiliki beberapa konsumen dalam grup konsumen. Untuk Functions, tujuan ini diterjemahkan ke banyak instans fungsi dalam paket. Hasilnya disebut sebagai paralelisme tingkat partisi atau tingkat paralelisme maksimum, seperti yang ditunjukkan pada diagram berikut:

Tingkat maksimum paralelisme

Tampaknya masuk akal untuk mengonfigurasi partisi sebanyak mungkin untuk mencapai throughput maksimum dan untuk memperhitungkan kemungkinan volume peristiwa yang lebih tinggi. Namun, ada beberapa faktor penting yang perlu dipertimbangkan ketika Anda mengonfigurasi banyak partisi:

  • Lebih banyak partisi dapat menyebabkan lebih banyak throughput: Karena tingkat paralelisme adalah jumlah konsumen (instans fungsi), semakin banyak partisi yang ada, semakin tinggi throughput bersamaan. Fakta ini penting ketika Anda berbagi sejumlah TU yang ditunjuk untuk pusat aktivitas dengan aplikasi konsumen lainnya.
  • Lebih banyak fungsi dapat memerlukan lebih banyak memori: Saat jumlah instans fungsi meningkat, begitu juga jejak memori sumber daya dalam rencana. Pada titik tertentu, terlalu banyak partisi yang dapat memburuk performa bagi konsumen.
  • Ada risiko tekanan balik dari layanan hilir: Karena lebih banyak throughput dihasilkan, Anda menjalankan risiko layanan hilir yang luar biasa atau menerima tekanan balik dari mereka. Fan-out konsumen harus diperhitungkan ketika mempertimbangkan konsekuensi terhadap sumber daya di sekitarnya. Kemungkinan konsekuensi termasuk pembatasan dari layanan lain, saturasi jaringan, dan bentuk ketidakcocokan sumber daya lainnya.
  • Partisi dapat diisi secara jarang: Kombinasi banyak partisi dan volume peristiwa yang rendah dapat menyebabkan data yang jarang didistribusikan di seluruh partisi. Sebaliknya, sejumlah kecil partisi dapat memberikan performa dan penggunaan sumber daya yang lebih baik.

Ketersediaan dan konsistensi

Saat kunci atau ID partisi tidak ditentukan, Azure Event Hubs merutekan peristiwa masuk ke partisi berikutnya yang tersedia. Praktik ini memberikan ketersediaan tinggi dan membantu meningkatkan throughput bagi konsumen.

Saat pengurutan serangkaian peristiwa diperlukan, produsen peristiwa dapat menentukan bahwa partisi tertentu akan digunakan untuk semua peristiwa set. Aplikasi konsumen yang membaca dari partisi menerima peristiwa dalam urutan yang tepat. Tradeoff ini memberikan konsistensi tetapi membahayakan ketersediaan. Jangan gunakan pendekatan ini kecuali urutan peristiwa harus dipertahankan.

Untuk Functions, urutan dilakukan saat peristiwa dipublikasikan ke partisi tertentu dan fungsi yang dipicu oleh Event Hubs mendapatkan sewa ke partisi yang sama. Saat ini, kemampuan untuk mengonfigurasi partisi dengan pengikatan output Azure Event Hubs tidak didukung. Sebagai gantinya, pendekatan terbaik adalah menggunakan salah satu SDK Azure Event Hubs untuk menerbitkan ke partisi tertentu.

Untuk informasi selengkapnya tentang bagaimana Azure Event Hubs mendukung ketersediaan dan konsistensi, lihat Ketersediaan dan konsistensi di Azure Event Hubs.

Pemicu Azure Event Hubs

Bagian ini berfokus pada pengaturan dan pertimbangan untuk mengoptimalkan fungsi yang dipicu Azure Event Hubs. Faktor-faktor termasuk pemrosesan batch, pengambilan sampel, dan fitur terkait yang memengaruhi perilaku pengikatan pemicu pusat aktivitas.

Batching untuk fungsi yang dipicu

Anda dapat mengonfigurasi fungsi yang dipicu hub peristiwa untuk memproses batch peristiwa atau satu peristiwa pada satu waktu. Memproses batch peristiwa bisa lebih efisien ketika mengurangi beberapa overhead pemanggilan fungsi. Kecuali Anda hanya perlu memproses satu peristiwa, fungsi Anda harus dikonfigurasi untuk memproses beberapa peristiwa saat dipanggil.

Mengaktifkan batch untuk pengikatan pemicu Event Hubs bervariasi antarbahasa:

  • JavaScript, Python, dan bahasa lain memungkinkan batching ketika properti kardinalitas diatur ke banyak dalam file function.json untuk fungsi tersebut.
  • Di C#, kardinalitas secara otomatis dikonfigurasi saat array ditunjuk untuk jenis di atribut EventHubTrigger .

Untuk informasi selengkapnya tentang cara pembuatan batch diaktifkan, lihat Pemicu Azure Event Hubs untuk Azure Functions.

Pengaturan pemicu

Beberapa pengaturan konfigurasi dalam file host.json memainkan peran utama dalam karakteristik performa pengikatan pemicu Azure Event Hubs untuk Functions:

  • maxEventBatchSize: Pengaturan ini mewakili jumlah maksimum peristiwa yang dapat diterima fungsi saat dipanggil. Jika jumlah peristiwa yang diterima kurang dari jumlah ini, fungsi masih dipanggil dengan sebanyak mungkin peristiwa yang tersedia. Anda tidak dapat mengatur ukuran batch minimum.
  • prefetchCount: Jumlah prefetch adalah salah satu pengaturan terpenting saat Anda mengoptimalkan performa. Saluran AMQP yang mendasar mereferensikan nilai ini untuk menentukan berapa banyak pesan yang akan diambil dan di-cache untuk klien. Jumlah prefetch harus lebih besar dari atau sama dengan nilai maxEventBatchSize dan biasanya diatur ke kelipatan jumlah tersebut. Mengatur nilai ini ke angka yang kurang dari pengaturan maxEventBatchSize dapat merusak performa.
  • batchCheckpointFrequency: Saat fungsi Anda memproses batch, nilai ini menentukan laju di mana titik pemeriksaan dibuat. Nilai default adalah 1, yang berarti bahwa ada titik pemeriksaan setiap kali fungsi berhasil memproses satu batch. Titik pemeriksaan dibuat di tingkat partisi untuk setiap pembaca di grup konsumen. Untuk informasi tentang bagaimana pengaturan ini memengaruhi pemutaran ulang dan percobaan ulang peristiwa, lihat Fungsi Azure yang dipicu hub peristiwa: Pemutaran Ulang dan Coba Lagi (posting blog).

Lakukan beberapa pengujian performa untuk menentukan nilai yang akan diatur untuk pengikatan pemicu. Kami menyarankan agar Anda mengubah pengaturan secara bertahap dan mengukur secara konsisten untuk menyempurnakan opsi ini. Nilai default adalah titik awal yang wajar untuk sebagian besar solusi pemrosesan peristiwa.

Checkpointing

Titik pemeriksaan menandai atau menerapkan posisi pembaca dalam urutan peristiwa partisi. Ini adalah tanggung jawab host Functions ke titik pemeriksaan saat peristiwa diproses dan pengaturan untuk frekuensi pos pemeriksaan batch terpenuhi. Untuk informasi selengkapnya tentang titik pemeriksaan, lihat Fitur dan terminologi di Azure Event Hubs.

Konsep berikut dapat membantu Anda memahami hubungan antara titik pemeriksaan dan cara fungsi Anda memproses peristiwa:

  • Pengecualian masih dihitung keberhasilan: Jika proses fungsi tidak crash saat memproses peristiwa, penyelesaian fungsi dianggap berhasil, bahkan jika pengecualian terjadi. Ketika fungsi selesai, host Functions mengevaluasi batchCheckpointFrequency. Jika sudah waktunya untuk titik pemeriksaan, titik pemeriksaan akan membuatnya, terlepas dari apakah ada pengecualian. Fakta bahwa pengecualian tidak memengaruhi titik pemeriksaan seharusnya tidak memengaruhi penggunaan pemeriksaan dan penanganan pengecualian yang tepat.
  • Frekuensi batch penting: Dalam solusi streaming peristiwa volume tinggi, dapat bermanfaat untuk mengubah pengaturan batchCheckpointFrequency ke nilai yang lebih besar dari 1. Meningkatkan nilai ini dapat mengurangi tingkat pembuatan titik pemeriksaan dan, sebagai konsekuensinya, jumlah operasi I/O penyimpanan.
  • Pemutaran ulang dapat terjadi: Setiap kali fungsi dipanggil dengan pengikatan pemicu Azure Event Hubs, fungsi ini menggunakan titik pemeriksaan terbaru untuk menentukan tempat melanjutkan pemrosesan. Offset untuk setiap konsumen disimpan di tingkat partisi untuk setiap grup konsumen. Pemutaran ulang terjadi ketika titik pemeriksaan tidak terjadi selama pemanggilan fungsi terakhir, dan fungsi dipanggil lagi. Untuk informasi selengkapnya tentang duplikat dan teknik deduplikasi, lihat Idempotency.

Memahami titik pemeriksaan menjadi penting ketika Anda mempertimbangkan praktik terbaik untuk penanganan kesalahan dan percobaan ulang, topik yang dibahas nanti di artikel ini.

Pengambilan sampel telemetri

Functions menyediakan dukungan bawaan untuk Application Insights, ekstensi Azure Monitor yang menyediakan kemampuan pemantauan performa aplikasi. Dengan fitur ini, Anda dapat mencatat informasi tentang aktivitas fungsi, performa, pengecualian runtime, dan banyak lagi. Untuk informasi selengkapnya, lihat Gambaran umum Application Insights.

Kemampuan canggih ini menawarkan beberapa pilihan konfigurasi utama yang memengaruhi performa. Beberapa pengaturan dan pertimbangan penting untuk pemantauan dan performa adalah:

  • Aktifkan pengambilan sampel telemetri: Untuk skenario throughput tinggi, Anda harus mengevaluasi jumlah telemetri dan informasi yang Anda butuhkan. Pertimbangkan untuk menggunakan fitur pengambilan sampel telemetri di Application Insights untuk menghindari penurunan performa fungsi Anda dengan telemetri dan metrik yang tidak perlu.
  • Mengonfigurasi pengaturan agregasi: Memeriksa dan mengonfigurasi frekuensi agregasi dan pengiriman data ke Application Insights. Pengaturan konfigurasi ini ada di file host.json bersama dengan banyak opsi terkait pengambilan sampel dan pengelogan lainnya. Untuk informasi selengkapnya, lihat Mengonfigurasi agregator.
  • Nonaktifkan AzureWebJobDashboard: Untuk aplikasi yang menargetkan versi 1.x dari runtime Functions, pengaturan ini menyimpan string koneksi ke akun penyimpanan yang digunakan Azure SDK untuk menyimpan log untuk dasbor WebJobs. Jika Application Insights digunakan alih-alih dasbor WebJobs, maka pengaturan ini harus dihapus. Untuk informasi selengkapnya, lihat AzureWebJobsDashboard.

Ketika Application Insights diaktifkan tanpa pengambilan sampel, semua telemetri dikirim. Mengirim data tentang semua peristiwa dapat memiliki efek yang merugikan pada performa fungsi, terutama di bawah skenario streaming peristiwa throughput tinggi.

Memanfaatkan pengambilan sampel dan terus menilai jumlah telemetri yang sesuai yang diperlukan untuk pemantauan sangat penting untuk performa optimal. Telemetri harus digunakan untuk evaluasi kesehatan platform umum dan untuk pemecahan masalah sesekali, bukan untuk menangkap metrik bisnis inti. Untuk informasi selengkapnya, lihat Mengonfigurasi pengambilan sampel.

Pengikatan output

Gunakan pengikatan output Azure Event Hubs untuk Azure Functions untuk menyederhanakan penerbitan ke aliran peristiwa dari fungsi. Manfaat menggunakan pengikatan ini meliputi:

  • Manajemen sumber daya: Pengikatan menangani siklus hidup klien dan koneksi untuk Anda, dan mengurangi potensi masalah yang dapat muncul dengan kelelahan port dan manajemen kumpulan koneksi.
  • Lebih sedikit kode: Pengikatan mengabstraksi SDK yang mendasar dan mengurangi jumlah kode yang perlu Anda terbitkan peristiwa. Ini membantu Anda menulis kode yang lebih mudah ditulis dan dikelola.
  • Batch: Untuk beberapa bahasa, batch didukung untuk memublikasikan secara efisien ke aliran peristiwa. Batching dapat meningkatkan performa dan membantu menyederhanakan kode yang mengirim peristiwa.

Kami sangat menyarankan Agar Anda meninjau daftar Bahasa yang didukung Functions dan panduan pengembang untuk bahasa tersebut. Bagian Pengikatan data untuk setiap bahasa memberikan contoh dan dokumentasi terperinci.

Batching saat menerbitkan peristiwa

Jika fungsi Anda hanya menerbitkan satu peristiwa, mengonfigurasi pengikatan untuk mengembalikan nilai adalah pendekatan umum yang berguna jika eksekusi fungsi selalu diakhiri dengan pernyataan yang mengirim peristiwa. Teknik ini hanya boleh digunakan untuk fungsi sinkron yang hanya mengembalikan satu peristiwa.

Batch didorong untuk meningkatkan performa saat mengirim beberapa peristiwa ke aliran. Batch memungkinkan pengikatan untuk memublikasikan peristiwa dengan cara yang paling efisien.

Dukungan untuk menggunakan pengikatan output untuk mengirim beberapa peristiwa ke Azure Event Hubs tersedia di C#, Java, Python, dan JavaScript.

Output beberapa peristiwa dengan model Dalam proses (C#)

Gunakan jenis ICollector dan IAsyncCollector saat Anda mengirim beberapa peristiwa dari fungsi di C#.

  • ICollector <T>. Metode Add() dapat digunakan dalam fungsi sinkron dan asinkron. Ini mengeksekusi operasi penambahan segera setelah dipanggil.
  • IAsyncCollector<T>. Metode AddAsync() menyiapkan peristiwa yang akan diterbitkan ke aliran peristiwa. Jika Anda menulis fungsi asinkron, Anda harus menggunakan IAsyncCollector untuk mengelola peristiwa yang diterbitkan dengan lebih baik.

Untuk contoh penggunaan C# untuk menerbitkan satu dan beberapa peristiwa, lihat Pengikatan output Azure Event Hubs untuk Azure Functions.

Output beberapa peristiwa dengan model pekerja Terisolasi (C#)

Bergantung pada versi runtime Functions, model pekerja Terisolasi akan mendukung berbagai jenis untuk parameter yang diteruskan ke pengikatan output. Untuk beberapa peristiwa, array digunakan untuk merangkum set. Disarankan untuk meninjau atribut pengikatan output dan detail penggunaan untuk model Terisolasi dan untuk mencatat perbedaan antara versi ekstensi.

Pembatasan dan tekanan belakang

Pertimbangan pembatasan berlaku untuk pengikatan output, tidak hanya untuk Azure Event Hubs tetapi juga untuk layanan Azure seperti Azure Cosmos DB. Penting untuk terbiasa dengan batas dan kuota yang berlaku untuk layanan tersebut dan untuk merencanakan yang sesuai.

Untuk menangani kesalahan hilir dengan model Dalam proses, Anda dapat membungkus AddAsync dan FlushAsync dalam handler pengecualian untuk .NET Functions untuk menangkap pengecualian dari IAsyncCollector. Opsi lain adalah menggunakan SDK Azure Event Hubs secara langsung alih-alih menggunakan pengikatan output.

Jika Anda memanfaatkan model Terisolasi untuk fungsi, maka penanganan pengecualian terstruktur harus digunakan untuk menangkap pengecualian secara bertanggung jawab saat mengembalikan nilai output.

Kode fungsi

Bagian ini mencakup area utama yang harus dipertimbangkan saat menulis kode untuk memproses peristiwa dalam fungsi yang dipicu Azure Event Hubs.

Pemrograman asinkron

Kami menyarankan agar Anda menulis fungsi Anda untuk menggunakan kode asinkron dan menghindari pemblokiran panggilan, terutama ketika panggilan I/O terlibat.

Berikut adalah panduan yang harus Anda ikuti saat menulis fungsi untuk diproses secara asinkron:

  • Semua asinkron atau semua sinkron: Jika fungsi dikonfigurasi untuk berjalan secara asinkron, semua panggilan I/O harus asinkron. Dalam kebanyakan kasus, sebagian kode asinkron lebih buruk daripada kode yang sepenuhnya sinkron. Pilih asinkron atau sinkron, dan tetap dengan pilihan sepanjang jalan.
  • Hindari memblokir panggilan: Memblokir panggilan kembali ke pemanggil hanya setelah panggilan selesai, berbeda dengan panggilan asinkron yang segera kembali. Contoh dalam C# adalah memanggil Task.Result atau Task.Wait pada operasi asinkron.

Selengkapnya tentang memblokir panggilan

Menggunakan panggilan pemblokiran untuk operasi asinkron dapat menyebabkan kelaparan kumpulan utas dan menyebabkan proses fungsi mengalami crash. Crash terjadi karena panggilan pemblokiran mengharuskan utas lain dibuat untuk mengimbangi panggilan asli yang sekarang menunggu. Akibatnya, dibutuhkan dua kali lebih banyak utas untuk menyelesaikan operasi.

Menghindari sinkronisasi ini melalui pendekatan asinkron sangat penting ketika Azure Event Hubs terlibat, karena crash fungsi tidak memperbarui titik pemeriksaan. Lain kali fungsi dipanggil itu bisa berakhir dalam siklus ini dan tampaknya macet atau bergerak perlahan karena eksekusi fungsi akhirnya kehabisan waktu.

Pemecahan masalah fenomena ini biasanya dimulai dengan meninjau pengaturan pemicu dan menjalankan eksperimen yang dapat melibatkan peningkatan jumlah partisi. Investigasi juga dapat menyebabkan perubahan beberapa opsi batch seperti ukuran batch maksimum atau jumlah prefetch. Kesannya adalah bahwa ini adalah masalah throughput atau pengaturan konfigurasi yang hanya perlu diatur dengan sesuai. Namun, masalah inti ada dalam kode itu sendiri dan harus ditangani di sana.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Sebelum melanjutkan, pertimbangkan untuk meninjau artikel terkait ini: