Bagikan melalui

Praktik terbaik untuk peningkatan performa menggunakan Azure Service Bus Messaging

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 dan diaktifkan untuk mengakomodasi lonjakan throughput.

Catatan

Jika tingkat yang tepat tidak dipilih, terdapat risiko kewalahan pada Service Bus namespace yang mungkin menyebabkan pembatasan.

Pengurangan laju tidak menyebabkan hilangnya data. Aplikasi yang menggunakan Service Bus SDK dapat menggunakan kebijakan coba lagi default untuk memastikan bahwa data akhirnya diterima oleh Service Bus.

Menghitung throughput untuk Premium

Data yang dikirim ke Service Bus dialihkan menjadi biner dan kemudian dideserialisasi ketika diterima oleh penerima. Jadi, sementara aplikasi menganggap pesan sebagai unit kerja atomik, 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 muatan pesan yang lebih kecil yang dapat dikelompokkan.

Tolak ukur

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

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

Pertimbangan dalam Komputasi

Service Bus mengoperasikan beberapa proses latar belakang yang dapat memengaruhi penggunaan komputasi. Ini termasuk, tetapi tidak terbatas pada, timer, jadwal, dan emisi metrik. Selain itu, menggunakan fitur Bus Layanan tertentu memerlukan pemanfaatan komputasi yang dapat mengurangi throughput yang diharapkan. Beberapa fitur ini adalah -

  1. Sesi.
  2. Menyalurkan berbagai 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. Disarankan untuk meningkatkan jumlah Unit Pesan (MUs) saat penggunaan CPU melebihi 70% untuk memastikan performa optimal.

Sharding di seluruh namespace

Meskipun meningkatkan alokasi Komputasi (Unit Olahpesan) ke namespace adalah solusi yang lebih mudah, tetapi itu mungkin tidak memberikan peningkatan linier dalam throughput. Ini disebabkan oleh komponen internal Service Bus (penyimpanan, jaringan, dll.) yang mungkin membatasi throughput.

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

Protokol

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

  1. Protokol Antrean Pesan Tingkat Lanjut (AMQP)
  2. Protokol Olahpesan 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. Beralih ke pustaka Azure Service Bus SDK terbaru menggunakan protokol AMQP, yang menawarkan pembaruan keamanan kritis dan kemampuan yang ditingkatkan, sebelum tanggal tersebut.

Untuk informasi selengkapnya, lihat pengumuman penghentian layanan dukungan.

Memilih 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 Utama Platform Minimum Protokol
Azure.Messaging.ServiceBus (terbaru) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Inti 2.0
Kerangka Kerja .NET 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 Inti 2.0
Kerangka Kerja .NET 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 memensiunkan pustaka SDK Azure Service Bus 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 layanan dukungan.

Menggunakan kembali pabrik dan pelanggan

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

Kami menyarankan agar Anda tidak menutup atau membuang klien ini setelah mengirim atau menerima setiap pesan. Menutup atau membuang objek khusus entitas (ServiceBusSender/Receiver/Processor) mengakibatkan pemutusan tautan ke layanan Service Bus. Mengakhiri ServiceBusClient mengakibatkan penghentian koneksi ke layanan 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. Ini berlaku untuk semua SDK kecuali klien Python. Untuk Python, kunci harus digunakan ketika menggunakan thread dan operasi asinkron bersamaan.

Operasi bersamaan

Operasi seperti mengirim, menerima, menghapus, dan sebagainya, membutuhkan waktu. Waktu ini mencakup waktu yang diperlukan oleh layanan Azure Service Bus untuk memproses operasi, serta 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 Penerimaan

Saat membuat antrean atau klien langganan, Anda dapat menentukan mode terima: Mengintip-dan-Mengunci atau Terima dan 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. Peningkatan kinerja ini datang dengan risiko kehilangan pesan.

Azure Service Bus tidak mendukung transaksi untuk operasi terima dan hapus. Selain itu, semantik peek-lock diperlukan untuk skenario apa pun di mana klien ingin menunda atau mengirim pesan ke antrian dead-letter.

Pemuatan Awal

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 yang di-prefetch tidak dapat diterima oleh penerima lain. 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 kedaluwarsa, atur ukuran cache yang lebih kecil dari jumlah pesan yang dapat digunakan klien dalam interval batas waktu kunci.

Ketika Anda menggunakan masa berlaku kunci bawaan 60 detik, nilai yang baik untuk PrefetchCount adalah 20 kali tingkat pemrosesan maksimum semua penerima di 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.

Prefetching pesan meningkatkan throughput keseluruhan untuk antrean atau langganan karena mengurangi jumlah keseluruhan operasi pesan, atau perjalanan bolak-balik. 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 ketika klien meng-cache pesan tersebut.

Prefetching tidak memengaruhi jumlah operasi pesan yang dapat ditagihkan dan hanya tersedia untuk protokol klien Service Bus. Protokol HTTP tidak mendukung prefetching. Prefetching tersedia untuk operasi penerimaan 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 agresif, yaitu menjaga jumlah prefetch tetap tinggi, karena mengindikasikan 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 Service Bus 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 yang signifikan.

Tingkat layanan yang Anda gunakan berdampak pada prediksi performa. Jika Anda memilih tingkat Standar, throughput dan latensi adalah usaha terbaik pada 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 bermuatan unit olahpesan yang lebih rendah (MU) memberikan kinerja yang lebih baik dibandingkan dengan satu partisi dengan MU yang lebih tinggi.

Skenario

Bagian berikut menjelaskan skenario pesan yang khas dan menguraikan pengaturan Service Bus yang disarankan. 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 untuk satu antrean. Jumlah pengirim dan penerimanya kecil.

  • Untuk meningkatkan tingkat pengiriman total ke antrean, gunakan beberapa generator pesan untuk membuat pengirim. Untuk setiap pengirim, gunakan operasi asinkron atau beberapa utas.
  • Untuk meningkatkan tingkat penerimaan keseluruhan dari antrean, gunakan beberapa penghasil pesan untuk membuat penerima.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima dari suatu instansi. Jumlah ini mengurangi jumlah transmisi protokol klien Service Bus.

Beberapa antrean dengan throughput tinggi

Sasaran: Memaksimalkan throughput keseluruhan dari beberapa antrean. Laju pemrosesan antrean individu adalah moderat atau tinggi.

Untuk mendapatkan kinerja maksimum melintasi beberapa antrean, gunakan pengaturan yang dijelaskan untuk memaksimalkan kinerja 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. Laju pemrosesan antrean kecil atau sedang.

  • 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.

Antrian dengan banyak pengirim

Sasaran: Memaksimalkan laju pemrosesan antrean atau topik dengan sejumlah besar pengirim. Setiap pengirim mengirim pesan dengan kecepatan sedang. Jumlah penerima kecil.

Service Bus memungkinkan hingga 1.000 koneksi bersamaan ke entitas pesan. 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.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima dari suatu instansi. Jumlah ini mengurangi jumlah transmisi protokol klien Service Bus.

Antrean dengan jumlah penerima yang besar

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

Service Bus memungkinkan hingga 1.000 koneksi secara 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 faktori per proses.
  • 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 yang memiliki beberapa langganan

Sasaran: Memaksimalkan throughput topik dengan sedikit 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 generator pesan untuk membuat penerima pesan. Untuk setiap penerima, gunakan operasi asinkron atau beberapa utas.
  • Atur jumlah prefetch menjadi 20 kali tingkat pemrosesan maksimum semua penerima dari suatu instansi. Jumlah ini mengurangi jumlah transmisi protokol klien Service Bus.

Topik dengan langganan dalam jumlah besar

Sasaran: Memaksimalkan throughput topik yang memiliki banyak 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.

Topik dengan sejumlah besar langganan biasanya menghasilkan throughput keseluruhan yang rendah karena semua pesan harus 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:

  • Atur jumlah prefetch menjadi 20 kali tingkat pesan yang diharapkan diterima. Jumlah ini mengurangi jumlah transmisi protokol klien Service Bus.
  • Last updated on