Praktik terbaik untuk peningkatan performa menggunakan Azure Service Bus Messaging

  • Artikel

Artikel ini menjelaskan cara menggunakan Azure Service Bus untuk mengoptimalkan performa saat bertukar pesan broker. Bagian pertama dari artikel ini menjelaskan mekanisme yang berbeda untuk meningkatkan performa. Bagian kedua memberikan panduan tentang penggunaan Azure Service Bus dengan cara yang dapat menawarkan performa terbaik dalam skenario tertentu.

Sepanjang artikel ini, istilah "klien" mengacu pada entitas apa pun yang mengakses Azure Service Bus. Klien dapat mengambil peran pengirim atau penerima. Istilah "pengirim" digunakan untuk klien antrean Azure Service Bus atau klien topik yang mengirim pesan ke antrean Azure Service Bus atau topik. Istilah "penerima" mengacu pada klien antrean Azure Service Bus atau klien langganan yang menerima pesan dari antrean Azure Service Bus atau langganan.

Perencanaan dan pertimbangan sumber daya

Seperti halnya resourcing teknis, perencanaan yang bijaksana adalah kunci dalam memastikan bahwa Azure Service Bus memberikan performa yang diharapkan aplikasi Anda. Konfigurasi atau topologi yang tepat untuk namespace Bus Layanan Anda bergantung pada sejumlah faktor yang melibatkan arsitektur aplikasi Anda dan bagaimana masing-masing fitur Bus Layanan digunakan.

Tingkatan harga

Azure Service Bus menawarkan berbagai tingkat harga. Disarankan untuk memilih tingkat yang sesuai untuk persyaratan aplikasi Anda.

  • Tingkat standar - Cocok untuk lingkungan pengembang/pengujian atau skenario throughput rendah di mana aplikasi tidak sensitif terhadap pembatasan.

  • Tingkat premium - Cocok untuk lingkungan produksi dengan persyaratan throughput yang bervariasi di mana latensi dan throughput yang dapat diprediksi diperlukan. Selain itu, namespace layanan premium Azure Service Bus dapat diskalakan secara otomatis dapat diaktifkan untuk mengakomodasi lonjakan throughput.

Catatan

Jika tingkat yang tepat tidak dipilih, ada risiko luar biasa namespace Azure Service Bus yang dapat menyebabkan pembatasan.

Pembatasan tidak menyebabkan hilangnya data. Aplikasi yang memanfaatkan SDK Bus Layanan dapat menggunakan kebijakan coba lagi default untuk memastikan bahwa data akhirnya diterima oleh Bus Layanan.

Menghitung throughput untuk Premium

Data yang dikirim ke Azure Service Bus diserialisasikan ke biner dan kemudian dideserialisasi ketika diterima oleh penerima. Dengan demikian, sementara aplikasi menganggap pesan sebagai unit pekerjaan atomik, Azure Service Bus mengukur throughput dalam hal byte (atau megabyte).

Saat menghitung persyaratan throughput, pertimbangkan data yang dikirim ke Azure Service Bus (ingress) dan data yang diterima dari Azure Service Bus (egress).

Seperti yang diharapkan, throughput lebih tinggi untuk payload pesan yang lebih kecil yang dapat ditumpuk bersama- sama.

Tolak ukur

Berikut adalah sampel GitHub yang dapat Anda jalankan untuk melihat throughput yang diharapkan yang Anda terima untuk namespace Bus Layanan Anda. Dalam pengujian tolok ukur kami, kami mengamati sekitar 4 MB/detik per Unit Pesan (MU) dari ingress dan egress.

Sampel tolok ukur tidak menggunakan fitur canggih apa pun, sehingga throughput yang diamati aplikasi Anda berbeda, berdasarkan skenario Anda.

Menghitung pertimbangan

Menggunakan fitur Bus Layanan tertentu memerlukan pemanfaatan komputasi yang dapat mengurangi throughput yang diharapkan. Beberapa fitur ini adalah -

  1. Sesi.
  2. Mengipasi beberapa langganan pada satu topik.
  3. Menjalankan banyak filter pada satu langganan.
  4. Pesan terjadwal.
  5. Pesan yang ditangguhkan.
  6. Transaksi.
  7. Deduplikasi & lihat kembali jendela waktu.
  8. Meneruskan ke (meneruskan dari satu entitas ke entitas lain).

Jika aplikasi Anda menggunakan salah satu fitur di atas dan Anda tidak menerima throughput yang diharapkan, Anda dapat meninjau metrik penggunaan CPU dan mempertimbangkan untuk meningkatkan namespace Bus Layanan Premium Anda.

Anda juga dapat menggunakan Azure Monitor untuk menskalakan namespace Azure Service Bus secara otomatis.

Sharding di seluruh namespace

Saat meningkatkan Komputasi (Unit Olahpesan) yang dialokasikan ke namespace layanan adalah solusi yang lebih mudah, itu mungkin tidak memberikan peningkatan linier dalam throughput. Ini karena Bus Layanan internal (penyimpanan, jaringan, dll.), yang mungkin membatasi throughput.

Solusi yang lebih bersih dalam hal ini adalah untuk memecah entitas Anda (antrean, dan topik) di berbagai namespace Azure Service Bus Premium. Anda juga dapat mempertimbangkan pemecahan di berbagai namespace layanan di wilayah Azure yang berbeda.

Protokol

Azure Service Bus memungkinkan klien mengirim dan menerima pesan melalui salah satu dari tiga protokol:

  1. Advanced Message Queuing Protocol (AMQP)
  2. Protokol Olahpesan Azure Service Bus (SBMP)
  3. Protokol Transfer Hiperteks (HTTP)

AMQP adalah yang paling efisien, karena mempertahankan koneksi ke Azure Service Bus. Ini juga mengimplementasikan batching dan prefetching. Kecuali disebutkan secara eksplisit, semua konten dalam artikel ini mengasumsikan penggunaan AMQP atau SBMP.

Penting

Protokol SBMP hanya tersedia untuk .NET Framework. AMQP adalah default untuk .NET Standard.

Pada 30 September 2026, kami akan menghentikan dukungan protokol SBMP untuk Azure Bus Layanan, sehingga Anda tidak akan dapat lagi menggunakan protokol ini setelah 30 September 2026. Migrasikan ke pustaka Azure Bus Layanan SDK terbaru menggunakan protokol AMQP, yang menawarkan pembaruan keamanan penting dan kemampuan yang ditingkatkan, sebelum tanggal tersebut.

Untuk informasi selengkapnya, lihat pengumuman penghentian dukungan.

Memilih Azure Service Bus .NET SDK yang sesuai

Paket Azure.Messaging.ServiceBus adalah Azure Service Bus .NET SDK terbaru yang tersedia mulai November 2020. Ada dua .NET SDK lama yang akan terus menerima perbaikan bug kritis hingga 30 September 2026, tetapi kami sangat mendorong Anda untuk menggunakan SDK terbaru sebagai gantinya. Baca panduan migrasi untuk detail tentang cara berpindah dari SDK lama.

Paket NuGet Namespace Primer Platform Minimum Protokol
Azure.Messaging.ServiceBus (terbaru) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Platform Windows Universal 10.0.16299		 AMQP
HTTP
Microsoft.Azure.ServiceBus Microsoft.Azure.ServiceBus
Microsoft.Azure.ServiceBus.Management		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Platform Windows Universal 10.0.16299		 AMQP
HTTP

Untuk informasi selengkapnya tentang dukungan platform .NET Standard minimum, lihat dukungan implementasi .NET.

Pada 30 September 2026, kami akan menghentikan pustaka Azure Bus Layanan SDK WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, dan com.microsoft.azure.servicebus, yang tidak sesuai dengan panduan Azure SDK. Kami juga akan mengakhiri dukungan protokol SBMP, sehingga Anda tidak akan lagi dapat menggunakan protokol ini setelah 30 September 2026. Migrasikan ke pustaka Azure SDK terbaru, yang menawarkan pembaruan keamanan penting dan kemampuan yang ditingkatkan, sebelum tanggal tersebut.

Meskipun pustaka lama masih dapat digunakan melebihi 30 September 2026, pustaka tersebut tidak akan lagi menerima dukungan dan pembaruan resmi dari Microsoft. Untuk informasi selengkapnya, lihat pengumuman penghentian dukungan.

Menggunakan kembali pabrik dan klien

Klien Bus Layanan yang berinteraksi dengan layanan, seperti ServiceBusClient, ServiceBusSender, ServiceBusReceiver, dan ServiceBusProcessor, harus didaftarkan untuk injeksi dependensi sebagai singleton (atau dibuat sekali dan dibagikan). ServiceBusClient dapat didaftarkan untuk injeksi dependensi dengan ServiceBusClientBuilderExtensions.

Kami menyarankan agar Anda tidak menutup atau membuang klien ini setelah mengirim atau menerima setiap pesan. Menutup atau membuang hasil (ServiceBusSender/Receiver/Processor) objek khusus entitas mengakibatkan kerusakan pada tautan ke layanan Azure Service Bus. Membuang hasil ServiceBusClient mengakibatkan kerusakan koneksi ke layanan Azure Service Bus.

Panduan ini tidak berlaku untuk ServiceBusSessionReceiver, karena masa pakainya sama dengan sesi itu sendiri. Untuk aplikasi yang bekerja dengan ServiceBusSessionReceiver, disarankan untuk menggunakan instans ServiceBusClient singleton untuk menerima setiap sesi, yang mencakup batas baru ServiceBusSessionReceiver ke sesi tersebut. Setelah aplikasi selesai memproses sesi tersebut, aplikasi harus membuang ServiceBusSessionReceiver.

Catatan berikut ini berlaku untuk semua SDK:

Catatan

Membuat koneksi adalah operasi mahal yang dapat Anda hindari dengan menggunakan kembali objek pabrik atau klien yang sama untuk beberapa operasi. Anda dapat dengan aman menggunakan objek klien ini untuk operasi asinkron bersamaan dan dari beberapa utas.

Operasi bersamaan

Operasi seperti mengirim, menerima, menghapus, dan sebagainya, membutuhkan waktu. Kali ini termasuk waktu yang diperlukan layanan Azure Service Bus untuk memproses operasi dan latensi permintaan dan respons. Untuk meningkatkan jumlah operasi per waktu, operasi harus dijalankan secara bersamaan.

Klien menjadwalkan operasi bersamaan dengan melakukan operasi asinkron. Permintaan berikutnya dimulai sebelum permintaan sebelumnya selesai. Cuplikan kode berikut adalah contoh operasi kirim asinkron:

var messageOne = new ServiceBusMessage(body);
var messageTwo = new ServiceBusMessage(body);

var sendFirstMessageTask =
    sender.SendMessageAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    sender.SendMessageAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

Kode berikut adalah contoh operasi terima asinkron.

var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions 
{

      AutoCompleteMessages = false,
      MaxConcurrentCalls = 20
};
await using ServiceBusProcessor processor = client.CreateProcessor(queueName,options);
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

static Task ErrorHandler(ProcessErrorEventArgs args)
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

static async Task MessageHandler(ProcessMessageEventArgs args)
{
    Console.WriteLine("Handle message");
    await args.CompleteMessageAsync(args.Message);
}

await processor.StartProcessingAsync();

Mode Terima

Saat membuat antrean atau klien langganan, Anda dapat menentukan mode terima: Kunci intip atau Terima and Hapus. Mode terima default adalah PeekLock. Saat beroperasi dalam mode default, klien akan mengirim permintaan untuk menerima pesan dari Azure Service Bus. Setelah klien menerima pesan, klien mengirim permintaan untuk menyelesaikan pesan.

Saat mengatur mode terima ke ReceiveAndDelete, kedua langkah digabungkan dalam satu permintaan. Langkah-langkah ini mengurangi jumlah operasi secara keseluruhan, dan dapat meningkatkan throughput pesan secara keseluruhan. Perolehan performa ini berisiko kehilangan pesan.

Azure Service Bus tidak mendukung transaksi untuk operasi terima dan hapus. Selain itu, semantik kunci intip diperlukan untuk skenario apa pun di mana klien ingin menunda atau menggagalkan surat pesan.

Prefetching

Prefetching memungkinkan antrean atau klien langganan memuat pesan tambahan dari layanan saat menerima pesan. Klien menyimpan pesan ini di cache lokal. Ukuran cache ditentukan oleh ServiceBusReceiver.PrefetchCount properti. Setiap klien yang memungkinkan prefetching mempertahankan cache sendiri. Cache tidak dibagikan di seluruh klien. Jika klien memulai operasi terima dan cache-nya kosong, layanan akan mengirimkan batch pesan. Jika klien memulai operasi terima dan cache berisi pesan, pesan diambil dari cache.

Ketika pesan di-prefetch, layanan mengunci pesan yang diambil sebelumnya. Dengan kunci, pesan di-prefetch tidak dapat diterima oleh penerima yang berbeda. Jika penerima tidak dapat menyelesaikan pesan sebelum kunci kedaluwarsa, pesan akan tersedia untuk penerima lain. Salinan pesan yang di-prefetch tetap ada di dalam cache. Penerima yang menggunakan salinan cache yang kedaluwarsa menerima pengecualian ketika mencoba menyelesaikan pesan tersebut. Secara default, kunci pesan kedaluwarsa setelah 60 detik. Nilai ini dapat diperpanjang hingga 5 menit. Untuk mencegah konsumsi pesan yang kedaluwarsa, atur ukuran cache yang lebih kecil dari jumlah pesan yang dapat digunakan klien dalam interval batas waktu penguncian.

Ketika Anda menggunakan kedaluwarsa kunci default 60 detik, nilai yang baik untuk PrefetchCount adalah 20 kali tingkat pemrosesan maksimum semua penerima pabrik. Misalnya, pabrik membuat tiga penerima, dan setiap penerima dapat memproses hingga 10 pesan per detik. Jumlah prefetch tidak boleh melebihi 20 X 3 X 10 = 600. Secara default, PrefetchCount diatur ke 0, yang berarti bahwa tidak ada pesan tambahan yang diambil dari layanan.

Pesan prefetching meningkatkan throughput keseluruhan untuk antrean atau langganan karena mengurangi jumlah keseluruhan operasi pesan, atau roundtrip. Pengambilan pesan pertama, bagaimanapun, membutuhkan waktu lebih lama (karena peningkatan ukuran pesan). Menerima pesan yang diambil sebelumnya dari cache lebih cepat karena pesan ini telah diunduh oleh klien.

Properti time-to-live (TTL) dari pesan diperiksa oleh server pada saat server mengirim pesan ke klien. Klien tidak memeriksa properti TTL pesan saat pesan diterima. Sebagai gantinya, pesan dapat diterima meskipun TTL pesan telah berlalu saat pesan di-cache oleh klien.

Prefetching tidak memengaruhi jumlah operasi pesan yang dapat ditagih, dan hanya tersedia untuk protokol klien Azure Service Bus. Protokol HTTP tidak mendukung prefetching. Prefetching tersedia untuk operasi terima sinkron dan asinkron.

Untuk informasi selengkapnya, lihat properti PrefetchCount berikut ini:

Anda dapat mengatur nilai untuk properti ini di ServiceBusReceiverOptions atau ServiceBusProcessorOptions.

Prefetching dan ReceiveMessagesAsync

Sementara konsep prefetching beberapa pesan bersama-sama memiliki semantik yang mirip dengan memproses pesan dalam batch (ReceiveMessagesAsync), ada beberapa perbedaan kecil yang harus diingat ketika menggunakan pendekatan ini bersama-sama.

Prefetch adalah konfigurasi (atau mode) pada ServiceBusReceiver dan ReceiveMessagesAsync merupakan operasi (yang memiliki semantik respons permintaan).

Saat menggunakan pendekatan ini bersama-sama, pertimbangkan kasus-kasus berikut -

  • Prefetch harus lebih besar dari atau sama dengan jumlah pesan yang Anda harapkan untuk menerima dari ReceiveMessagesAsync.
  • Prefetch dapat mencapai n/3 kali jumlah pesan yang diproses per detik, di mana n adalah durasi kunci default.

Ada beberapa tantangan dengan memiliki pendekatan serakah, yaitu menjaga jumlah prefetch tetap tinggi, karena menyiratkan bahwa pesan terkunci pada penerima tertentu. Kami menyarankan agar Anda mencoba nilai prefetch yang berada di antara ambang batas yang disebutkan sebelumnya, dan mengidentifikasi apa yang cocok.

Beberapa antrean atau topik

Jika satu antrean atau topik tidak dapat menangani jumlah pesan yang diharapkan, gunakan beberapa entitas olahpesan. Saat menggunakan beberapa entitas, buat klien khusus untuk setiap entitas, sebagai ganti menggunakan klien yang sama untuk semua entitas.

Lebih banyak antrean atau topik berarti Anda memiliki lebih banyak entitas untuk dikelola pada waktu penyebaran. Dari perspektif skalabilitas, sebenarnya tidak terlalu banyak perbedaan yang akan Anda perhatikan karena Bus Layanan sudah menyebarkan beban di beberapa log secara internal, jadi jika Anda menggunakan enam antrean atau topik atau dua antrean atau topik tidak akan membuat perbedaan material.

Tingkat layanan yang Anda gunakan berdampak pada prediksi performa. Jika Anda memilih tingkat Standar , throughput, dan latensi adalah upaya terbaik daripada infrastruktur multipenyewa bersama. Penyewa lain pada kluster yang sama dapat memengaruhi throughput Anda. Jika Anda memilih Premium, Anda mendapatkan sumber daya yang memberi Anda performa yang dapat diprediksi, dan beberapa antrean atau topik Anda diproses dari kumpulan sumber daya tersebut. Untuk informasi selengkapnya, lihat Tingkatan harga.

Namespace yang dipartisi

Saat Anda menggunakan namespace tingkat premium yang dipartisi, beberapa partisi dengan unit olahpesan yang lebih rendah (MU) memberi Anda performa yang lebih baik atas satu partisi dengan MUs yang lebih tinggi.

Skenario

Bagian berikut ini menjelaskan skenario Olahpesan yang khas dan menguraikan pengaturan Azure Service Bus pilihan. Tingkat throughput diklasifikasikan sebagai kecil (kurang dari 1 pesan/detik), sedang (1 pesan/detik atau lebih besar tetapi kurang dari 100 pesan/detik), dan tinggi (100 pesan/detik atau lebih besar). Jumlah klien diklasifikasikan sebagai kecil (5 atau kurang), sedang (lebih dari 5 tetapi kurang dari atau sama dengan 20), dan besar (lebih dari 20).

Antrean dengan throughput tinggi

Sasaran: Memaksimalkan throughput dari satu antrean. Jumlah pengirim dan penerimanya kecil.

  • Untuk meningkatkan tingkat pengiriman keseluruhan ke dalam antrean, gunakan beberapa pabrik pesan untuk membuat pengirim. Untuk setiap pengirim, gunakan operasi asinkron atau beberapa utas.
  • Untuk meningkatkan tingkat penerimaan keseluruhan dari antrean, gunakan beberapa pabrik pesan untuk membuat penerima.
  • Gunakan operasi asinkron untuk memanfaatkan batching sisi klien.
  • Biarkan akses penyimpanan yang di-batch diaktifkan. Akses ini meningkatkan tingkat keseluruhan di mana pesan dapat ditulis ke dalam antrean.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima pabrik. Jumlah ini mengurangi jumlah transmisi protokol klien Azure Service Bus.

Beberapa antrean dengan throughput tinggi

Sasaran: Memaksimalkan throughput keseluruhan dari beberapa antrean. Throughput dari antrean individu sedang atau tinggi.

Untuk mendapatkan throughput maksimum di beberapa antrean, gunakan pengaturan yang diuraikan untuk memaksimalkan throughput dari satu antrean. Selain itu, gunakan pabrik yang berbeda untuk membuat klien yang mengirim atau menerima dari antrean yang berbeda.

Antrean latensi rendah

Sasaran: Meminimalkan latensi antrean atau topik. Jumlah pengirim dan penerimanya kecil. Throughput antrean kecil atau sedang.

  • Nonaktifkan batching sisi klien. Klien segera mengirim pesan.
  • Nonaktifkan akses penyimpanan yang di-batch. Layanan segera menulis pesan ke penyimpanan.
  • Jika menggunakan satu klien, atur jumlah prefetch menjadi 20 kali tingkat pemrosesan penerima. Jika beberapa pesan masuk dalam antrean pada saat yang sama, protokol klien Azure Service Bus mengirimkan semuanya secara bersamaan. Ketika klien menerima pesan berikutnya, pesan tersebut sudah ada di cache lokal. Cache harus kecil.
  • Jika menggunakan beberapa klien, atur jumlah prefetch ke 0. Dengan mengatur hitungan, klien kedua dapat menerima pesan kedua saat klien pertama masih memproses pesan pertama.

Antrean dengan pengirim dalam jumlah besar

Sasaran: Maksimalkan throughput antrean atau topik dengan sejumlah besar pengirim. Setiap pengirim mengirim pesan dengan tarif sedang. Jumlah penerima kecil.

Bus Layanan memungkinkan hingga 1.000 koneksi bersamaan ke entitas olahpesan. Batas ini diberlakukan pada tingkat namespace, dan antrean, topik, atau langganan dibatasi oleh batas koneksi bersamaan per namespace. Untuk antrean, nomor ini dibagi antara pengirim dan penerima. Jika semua 1.000 koneksi diperlukan untuk pengirim, ganti antrean dengan topik dan satu langganan. Topik menerima hingga 1.000 koneksi bersamaan dari pengirim. Langganan menerima tambahan 1.000 koneksi bersamaan dari penerima. Jika diperlukan lebih dari 1.000 pengirim bersamaan, pengirim harus mengirim pesan ke protokol Bus Layanan melalui HTTP.

Untuk memaksimalkan throughput, ikuti langkah-langkah ini:

  • Jika setiap pengirim berada dalam proses yang berbeda, gunakan hanya satu pabrik per proses.
  • Gunakan operasi asinkron untuk memanfaatkan batching sisi klien.
  • Biarkan akses penyimpanan yang di-batch diaktifkan. Akses ini menaikkan tingkat keseluruhan di mana pesan dapat ditulis ke dalam antrean atau topik.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima pabrik. Jumlah ini mengurangi jumlah transmisi protokol klien Azure Service Bus.

Antrean dengan penerima dalam jumlah besar

Sasaran: Maksimalkan tingkat penerimaan antrean atau langganan dengan penerima dalam jumlah besar. Setiap penerima akan menerima pesan dengan laju sedang. Jumlah pengirimnya kecil.

Bus Layanan memungkinkan hingga 1.000 koneksi bersamaan ke entitas. Jika antrean memerlukan lebih dari 1.000 penerima, ganti antrean dengan topik dan beberapa langganan. Setiap langganan dapat mendukung hingga 1.000 koneksi bersamaan. Atau, penerima dapat mengakses antrean melalui protokol HTTP.

Untuk memaksimalkan throughput, ikuti panduan ini:

  • Jika setiap penerima berada dalam proses yang berbeda, gunakan hanya satu pabrik per proses.
  • Penerima dapat menggunakan operasi sinkron atau asinkron. Mengingat tingkat penerimaan moderat dari penerima individu, batching sisi klien dari permintaan Lengkap tidak memengaruhi throughput penerima.
  • Biarkan akses penyimpanan yang di-batch diaktifkan. Akses ini mengurangi beban keseluruhan entitas. Akses ini menaikkan tingkat keseluruhan di mana pesan dapat ditulis ke dalam antrean atau topik.
  • Atur jumlah prefetch ke nilai kecil (misalnya, PrefetchCount = 10). Jumlah ini mencegah penerima agar tetap aktif sementara penerima lain memiliki sejumlah besar pesan yang di-cache.

Topik dengan beberapa langganan

Sasaran: Memaksimalkan throughput topik dengan beberapa langganan. Pesan diterima oleh banyak langganan, yang berarti tingkat terima gabungan atas semua langganan lebih besar dari tingkat pengiriman. Jumlah pengirimnya kecil. Jumlah penerima per langganan kecil.

Untuk memaksimalkan throughput, ikuti panduan ini:

  • Untuk meningkatkan tingkat pengiriman keseluruhan ke dalam topik, gunakan beberapa pabrik pesan untuk membuat pengirim. Untuk setiap pengirim, gunakan operasi asinkron atau beberapa utas.
  • Untuk meningkatkan tingkat penerimaan keseluruhan dari langganan, gunakan beberapa pabrik pesan untuk membuat penerima. Untuk setiap penerima, gunakan operasi asinkron atau beberapa utas.
  • Gunakan operasi asinkron untuk memanfaatkan batching sisi klien.
  • Biarkan akses penyimpanan yang di-batch diaktifkan. Akses ini meningkatkan tingkat keseluruhan di mana pesan dapat ditulis ke dalam topik.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima pabrik. Jumlah ini mengurangi jumlah transmisi protokol klien Azure Service Bus.

Topik dengan langganan dalam jumlah besar

Sasaran: Memaksimalkan throughput topik dengan langganan dalam jumlah besar. Pesan diterima oleh banyak langganan, yang berarti tingkat terima gabungan atas semua langganan lebih besar dari tingkat pengiriman. Jumlah pengirimnya kecil. Jumlah penerima per langganan kecil.

Topik dengan sejumlah besar langganan biasanya mengekspos throughput keseluruhan yang rendah jika semua pesan dirutekan ke semua langganan. Ini karena setiap pesan diterima berkali-kali, dan semua pesan dalam sebuah topik dan semua langganannya disimpan di penyimpanan yang sama. Asumsinya adalah bahwa jumlah pengirim dan jumlah penerima per langganan kecil. Azure Service Bus mendukung hingga 2.000 langganan per topik.

Untuk memaksimalkan throughput, cobalah langkah-langkah berikut:

  • Gunakan operasi asinkron untuk memanfaatkan batching sisi klien.
  • Biarkan akses penyimpanan yang di-batch diaktifkan. Akses ini meningkatkan tingkat keseluruhan di mana pesan dapat ditulis ke dalam topik.
  • Atur jumlah prefetch menjadi 20 kali tingkat yang diharapkan di mana pesan diterima. Jumlah ini mengurangi jumlah transmisi protokol klien Azure Service Bus.