Service Bus Mesajlaşması kullanarak performans geliştirmek için en iyi yöntemler

  • Makale

Bu makalede, aracılı iletilerin alışverişi sırasında performansı iyileştirmek için Azure Service Bus'ın nasıl kullanılacağı açıklanmaktadır. Bu makalenin ilk bölümünde performansı artırmaya yönelik farklı mekanizmalar açıklanmaktadır. İkinci bölüm, Service Bus'ın belirli bir senaryoda en iyi performansı sunabilecek şekilde kullanılmasına yönelik rehberlik sağlar.

Bu makale boyunca , "istemci" terimi Service Bus'a erişen herhangi bir varlığı ifade eder. İstemci, gönderen veya alıcı rolünü üstlenebilir. "Gönderen" terimi, Service Bus kuyruğu istemcisi veya Service Bus kuyruğuna veya konuya ileti gönderen bir konu istemcisi için kullanılır. "Alıcı" terimi, Service Bus kuyruğundan veya abonelikten ileti alan bir Service Bus kuyruğu istemcisini veya abonelik istemcisini ifade eder.

Kaynak planlaması ve dikkat edilmesi gerekenler

Her teknik kaynakta olduğu gibi, Azure Service Bus'ın uygulamanızın beklediği performansı sağladığından emin olmak için ihtiyatlı planlama önemlidir. Service Bus ad alanlarınız için doğru yapılandırma veya topoloji, uygulama mimarinizi ve Service Bus özelliklerinin her birinin nasıl kullanıldığıyla ilgili faktörlerin bir konağına bağlıdır.

Fiyatlandırma katmanı

Service Bus çeşitli fiyatlandırma katmanları sunar. Uygulama gereksinimleriniz için uygun katmanı seçmeniz önerilir.

  • Standart katman : Uygulamaların azaltmaya duyarlı olmadığı geliştirici/test ortamları veya düşük aktarım hızı senaryoları için uygundur.

  • Premium katman - Öngörülebilir gecikme süresi ve aktarım hızı gerektiren çeşitli aktarım hızı gereksinimlerine sahip üretim ortamları için uygundur. Ayrıca Service Bus premium ad alanları otomatik olarak ölçeklendirilebilir ve aktarım hızındaki ani artışları karşılamak için etkinleştirilebilir.

Not

Doğru katman seçilmemişse, Service Bus ad alanını bunaltma riski vardır ve bu da azaltmaya neden olabilir.

Azaltma, veri kaybına yol açmaz. Service Bus SDK'sını kullanan uygulamalar, verilerin Service Bus tarafından kabul edilmesini sağlamak için varsayılan yeniden deneme ilkesini kullanabilir.

Premium için aktarım hızını hesaplama

Service Bus'a gönderilen veriler ikili olarak seri hale getirilir ve alıcı tarafından alındığında seri durumdan çıkarılır. Bu nedenle, uygulamalar iletileri atomik iş birimleri olarak düşünse de Service Bus aktarım hızını bayt (veya megabayt) cinsinden ölçer.

Aktarım hızı gereksinimini hesaplarken Service Bus'a (giriş) gönderilen verileri ve Service Bus'tan (çıkış) alınan verileri göz önünde bulundurun.

Beklendiği gibi, birlikte toplu işlenebilen daha küçük ileti yükleri için aktarım hızı daha yüksektir.

Karşılaştırmalar

Service Bus ad alanınız için beklenen aktarım hızını görmek için çalıştırabileceğiniz bir GitHub örneği aşağıda verilmiştir. Karşılaştırmalı testlerimizde, giriş ve çıkış için Mesajlaşma Birimi (MU) başına yaklaşık 4 MB/saniye gözlemledik.

Karşılaştırma örneği herhangi bir gelişmiş özellik kullanmadığından, uygulamalarınızın gözlemlediği aktarım hızı senaryolarınıza göre farklıdır.

İşlemle ilgili dikkat edilmesi gerekenler

Bazı Service Bus özelliklerini kullanmak için beklenen aktarım hızını azaltabilecek işlem kullanımı gerekir. Bu özelliklerden bazıları şunlardır:

  1. Oturum.
  2. Tek bir konuda birden çok aboneliğe yayma.
  3. Tek bir abonelikte birçok filtre çalıştırma.
  4. Zamanlanmış iletiler.
  5. Ertelenen iletiler.
  6. Hareket.
  7. Yinelenenleri kaldırma ve arka arkaya bakma zaman penceresi.
  8. İlet (bir varlıktan diğerine iletme).

Uygulamanız yukarıdaki özelliklerden herhangi birini kullanıyorsa ve beklenen aktarım hızını almıyorsanız, CPU kullanım ölçümlerini gözden geçirebilir ve Service Bus Premium ad alanınızın ölçeğini artırmayı düşünebilirsiniz.

Service Bus ad alanını otomatik olarak ölçeklendirmek için Azure İzleyici'yi de kullanabilirsiniz.

Ad alanları arasında parçalama

Ad alanına ayrılan İşlem (Mesajlaşma Birimleri) ölçeğini artırmak daha kolay bir çözüm olsa da, aktarım hızına doğrusal bir artış sağlamayabilir . Bunun nedeni Service Bus iç bileşenlerinin (depolama, ağ vb.) aktarım hızını sınırlaması olabilir.

Bu durumda daha temiz bir çözüm, varlıklarınızı (kuyruklar ve konular) farklı Service Bus Premium ad alanları arasında parçalamaktır. Ayrıca farklı Azure bölgelerindeki farklı ad alanları arasında parçalama yapmayı da düşünebilirsiniz.

Protokoller

Service Bus istemcilerin üç protokolden biri aracılığıyla ileti gönderip almasını sağlar:

  1. Gelişmiş İleti Sıraya Alma Protokolü (AMQP)
  2. Service Bus Mesajlaşma Protokolü (SBMP)
  3. Köprü Metni Aktarım Protokolü (HTTP)

AMQP, Service Bus bağlantısını koruduğundan en verimli yöntemdir. Ayrıca toplu işlem ve ön işlem uygular. Açıkça belirtilmediği sürece, bu makaledeki tüm içerikler AMQP veya SBMP kullanımını varsayar.

Önemli

SBMP protokolü yalnızca .NET Framework için kullanılabilir. AMQP, .NET Standard için varsayılan değerdir.

30 Eylül 2026'da Azure Service Bus için SBMP protokolü desteğini devre dışı bırakacağız, böylece 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve gelişmiş özellikler sunan AMQP protokolunu kullanarak en son Azure Service Bus SDK kitaplıklarına geçiş yapın.

Daha fazla bilgi için bkz . destek kullanımdan kaldırma duyurusu.

Uygun Service Bus .NET SDK'sını seçme

Paket Azure.Messaging.ServiceBus , Kasım 2020 itibarıyla kullanılabilen en son Azure Service Bus .NET SDK'sıdır. 30 Eylül 2026'ya kadar kritik hata düzeltmeleri almaya devam edecek iki eski .NET SDK'sı vardır, ancak bunun yerine en son SDK'yı kullanmanızı kesinlikle öneririz. Eski SDK'lardan nasıl geçiş yapılacağının ayrıntıları için geçiş kılavuzunu okuyun.

NuGet Paketi Birincil Ad Alanları En Düşük Platformlar Protokoller
Azure.Messaging.ServiceBus (en son) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Evrensel Windows Platformu 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
Evrensel Windows Platformu 10.0.16299		 AMQP
HTTP

En düşük .NET Standart platform desteği hakkında daha fazla bilgi için bkz . .NET uygulama desteği.

30 Eylül 2026'da Azure SDK yönergelerine uymayan WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus ve com.microsoft.azure.servicebus Azure Service Bus SDK kitaplıklarını kullanımdan kaldıracağız. Ayrıca SBMP protokolünün desteğini de sonlandıracağız, bu nedenle 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve geliştirilmiş özellikler sunan en son Azure SDK kitaplıklarına geçiş yapın.

Eski kitaplıklar 30 Eylül 2026'dan sonra da kullanılabilir olsa da artık Microsoft'tan resmi destek ve güncelleştirmeler almayacaktır. Daha fazla bilgi için bkz . destek kullanımdan kaldırma duyurusu.

Fabrikaları ve istemcileri yeniden kullanıyor

ServiceBusClient, ServiceBusSender, ServiceBusReceiver ve ServiceBusProcessor gibi hizmetle etkileşim kuran Service Bus istemcileri, bağımlılık ekleme için tekil olarak kaydedilmelidir (veya bir kez ve paylaşılan olarak örneklenmelidir). ServiceBusClient, ServiceBusClientBuilderExtensions ile bağımlılık ekleme için kaydedilebilir.

Her iletiyi gönderdikten veya aldıktan sonra bu istemcileri kapatmamanızı veya atmamanızı öneririz. Varlığa özgü nesnelerin (ServiceBusSender/Alıcı/İşlemci) kapatılması veya devre dışı bırakılması, Service Bus hizmetinin bağlantısının kapatılmasına neden olur. ServiceBusClient'ın devre dışı bırakılması, Service Bus hizmeti bağlantısının kesilmesine neden olur.

Kullanım ömrü oturumun kendisiyle aynı olduğundan bu kılavuz ServiceBusSessionReceiver için geçerli değildir. ile ServiceBusSessionReceiverçalışan uygulamalar için, her oturumu kabul etmek için öğesinin ServiceBusClient tek bir örneğinin kullanılması önerilir ve bu da bu oturuma yeni ServiceBusSessionReceiver bir sınır ekler. Uygulama bu oturumu işlemeyi tamamladıktan sonra ilişkili ServiceBusSessionReceiveröğesini atmalıdır.

Aşağıdaki not tüm SDK'lar için geçerlidir:

Not

Bağlantı kurmak, aynı fabrikayı veya istemci nesnelerini birden çok işlem için yeniden kullanarak kaçınabileceğiniz pahalı bir işlemdir. Bu istemci nesnelerini eşzamanlı zaman uyumsuz işlemler ve birden çok iş parçacığı için güvenle kullanabilirsiniz.

Eşzamanlı işlemler

Gönderme, alma, silme gibi işlemler biraz zaman alır. Bu süre, Service Bus hizmetinin işlemi işlemek için geçen süreyi, isteğin ve yanıtın gecikme süresini içerir. Zaman başına işlem sayısını artırmak için işlemlerin eşzamanlı olarak yürütülmesi gerekir.

İstemci, zaman uyumsuz işlemler gerçekleştirerek eşzamanlı işlemler zamanlar. Sonraki istek, önceki istek tamamlanmadan önce başlatılır. Aşağıdaki kod parçacığı, zaman uyumsuz gönderme işlemi örneğidir:

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");

Aşağıdaki kod, zaman uyumsuz alma işlemi örneğidir.

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();

Alma modu

Kuyruk veya abonelik istemcisi oluştururken bir alma modu belirtebilirsiniz: Göz atma-kilitleme veya Alma ve Silme. Varsayılan alma modu şeklindedir PeekLock. Varsayılan modda çalışırken, istemci Service Bus'tan bir ileti almak için bir istek gönderir. İstemci iletiyi aldıktan sonra, iletiyi tamamlamak için bir istek gönderir.

Alma modunu olarak ReceiveAndDeleteayarlarken her iki adım da tek bir istekte birleştirilir. Bu adımlar genel işlem sayısını azaltır ve genel ileti aktarım hızını iyileştirebilir. Bu performans kazancı iletileri kaybetme riskiyle karşı karşıya gelir.

Service Bus, alma ve silme işlemleri için işlemleri desteklemez. Ayrıca, istemcinin iletiyi ertelemek veya geri göndermek istediği senaryolar için peek-lock semantiği gereklidir.

Önceden hazırlama

Önceden oluşturma , kuyruk veya abonelik istemcisinin ileti aldığında hizmetten ek iletiler yüklemesini sağlar. İstemci bu iletileri yerel önbellekte depolar. Önbelleğin boyutu özellikler tarafından ServiceBusReceiver.PrefetchCount belirlenir. Önceden hazırlamayı etkinleştiren her istemci kendi önbelleğini korur. Önbellek istemciler arasında paylaşılamaz. İstemci bir alma işlemi başlatırsa ve önbelleği boşsa, hizmet bir dizi ileti iletir. İstemci bir alma işlemi başlatırsa ve önbellek bir ileti içeriyorsa, ileti önbellekten alınır.

Bir ileti önceden yüklendiğinde, hizmet önceden yüklenmiş iletiyi kilitler. Kilit ile önceden oluşturulmuş ileti farklı bir alıcı tarafından alınamaz. Alıcı, kilidin süresi dolmadan önce iletiyi tamamlayamazsa, ileti diğer alıcıların kullanımına sunulur. İletinin önceden oluşturulmuş kopyası önbellekte kalır. Süresi dolan önbelleğe alınmış kopyayı kullanan alıcı, bu iletiyi tamamlamaya çalıştığında bir özel durum alır. Varsayılan olarak, ileti kilidinin süresi 60 saniye sonra dolar. Bu değer 5 dakikaya uzatılabilir. Süresi dolan iletilerin tüketimini önlemek için önbellek boyutunu, istemcinin kilit zaman aşımı aralığı içinde kullanabileceği ileti sayısından daha küçük bir boyuta ayarlayın.

60 saniyelik varsayılan kilit süre sonunu kullandığınızda, için iyi bir değer PrefetchCount , fabrikanın tüm alıcılarının maksimum işlem hızlarının 20 katıdır. Örneğin, bir fabrika üç alıcı oluşturur ve her alıcı saniyede en fazla 10 ileti işleyebilir. Ön koşul sayısı 20 X 3 X 10 = 600'ü aşmamalıdır. Varsayılan olarak, PrefetchCount 0 olarak ayarlanır, bu da hizmetten ek ileti getirilmediği anlamına gelir.

İletilerin önceden eklenmesi, ileti işlemlerinin veya gidiş dönüşlerin toplam sayısını azalttığı için bir kuyruk veya abonelik için genel aktarım hızını artırır. Ancak ilk iletinin getirilma süresi daha uzun sürer (ileti boyutunun artması nedeniyle). Bu iletiler istemci tarafından zaten indirilmiş olduğundan önbellekten önceden oluşturulmuş iletilerin alınması daha hızlıdır.

Bir iletinin yaşam süresi (TTL) özelliği, sunucu iletiyi istemciye gönderdiği sırada sunucu tarafından denetlenmektedir. İstemci, ileti alındığında iletinin TTL özelliğini denetlemez. Bunun yerine, ileti istemci tarafından önbelleğe alınırken iletinin TTL'sinin geçmesine rağmen ileti alınabiliyor.

Önceden oluşturma, faturalanabilir mesajlaşma işlemlerinin sayısını etkilemez ve yalnızca Service Bus istemci protokolü için kullanılabilir. HTTP protokolü önceden hazırlamayı desteklemez. Prefetching hem zaman uyumlu hem de zaman uyumsuz alma işlemleri için kullanılabilir.

Daha fazla bilgi için aşağıdaki PrefetchCount özelliklere bakın:

ServiceBusReceiverOptions veya ServiceBusProcessorOptions içinde bu özellikler için değerler ayarlayabilirsiniz.

Önceden Oluşturma ve ReceiveMessagesAsync

Birden çok iletiyi birlikte önceden oluşturma kavramları, iletileri toplu olarak işlemeye benzer semantiklere (ReceiveMessagesAsync ) sahip olsa da, bu yaklaşımları birlikte kullanırken göz önünde bulundurulması gereken bazı küçük farklılıklar vardır.

Prefetch, ServiceBusReceiver üzerindeki bir yapılandırmadır (veya modudur) ve ReceiveMessagesAsync bir işlemdir (istek-yanıt semantiğine sahiptir).

Bu yaklaşımları birlikte kullanırken aşağıdaki durumları göz önünde bulundurun:

  • Ön koşul, 'den ReceiveMessagesAsyncalmayı beklediğiniz ileti sayısından büyük veya buna eşit olmalıdır.
  • Prefetch, saniye başına işlenen ileti sayısının en fazla n/3 katı olabilir; burada n varsayılan kilit süresidir.

Doyumsuz bir yaklaşıma sahip olmanın, yani iletinin belirli bir alıcıya kilitlendiği anlamına geldiği için prefetch sayısını yüksek tutmanın bazı zorlukları vardır. Daha önce bahsedilen eşikler arasındaki önceden oluşturulmuş değerleri denemenizi ve hangi değerlerin uygun olduğunu belirlemenizi öneririz.

Birden çok kuyruk veya konu başlığı

Tek bir kuyruk veya konu beklenen ileti sayısını işleyemiyorsa, birden çok mesajlaşma varlığı kullanın. Birden çok varlık kullanırken, tüm varlıklar için aynı istemciyi kullanmak yerine her varlık için ayrılmış bir istemci oluşturun.

Daha fazla kuyruk veya konu başlığı, dağıtım zamanında yönetecek daha fazla varlığınız olduğu anlamına gelir. Ölçeklenebilirlik açısından bakıldığında, Service Bus zaten yükü dahili olarak birden çok günlükte yaydığından fark edeceğiniz çok fazla bir fark yoktur. Bu nedenle altı kuyruk veya konu başlığı ya da iki kuyruk veya konu kullanırsanız önemli bir fark yaratmazsınız.

Kullandığınız hizmet katmanı, performans öngörülebilirliğini etkiler. Standart katman'ı seçerseniz aktarım hızı ve gecikme süresi, paylaşılan çok kiracılı bir altyapı üzerinde en iyi çabayı gösterir. Aynı kümedeki diğer kiracılar aktarım hızınızı etkileyebilir. Premium'u seçerseniz, size öngörülebilir performans sağlayan kaynaklar elde edersiniz ve birden çok kuyruğunuz veya konu başlığınız bu kaynak havuzundan işlenir. Daha fazla bilgi için bkz . Fiyatlandırma katmanları.

Bölümlenmiş ad alanları

Bölümlenmiş premium katman ad alanlarını kullandığınızda, daha düşük mesajlaşma birimlerine (MU) sahip birden çok bölüm, daha yüksek MU'lara sahip tek bir bölüm üzerinde daha iyi bir performans sağlar.

Senaryolar

Aşağıdaki bölümlerde tipik mesajlaşma senaryoları açıklanır ve tercih edilen Service Bus ayarları özetlenir. Aktarım hızı küçük (1 ileti/saniyeden az), orta (1 ileti/saniye veya daha büyük ama 100 ileti/saniyeden az) ve yüksek (100 ileti/saniye veya daha büyük) olarak sınıflandırılır. İstemci sayısı küçük (5 veya daha az), orta (5'ten fazla ama 20'den küçük veya buna eşit) ve büyük (20'den fazla) olarak sınıflandırılır.

Yüksek aktarım hızı kuyruğu

Hedef: Tek bir kuyruğun aktarım hızını en üst düzeye çıkarın. Gönderenlerin ve alıcıların sayısı azdır.

  • Kuyruğa genel gönderme oranını artırmak için, gönderen oluşturmak için birden çok ileti fabrikası kullanın. Her gönderen için zaman uyumsuz işlemler veya birden çok iş parçacığı kullanın.
  • Kuyruktan genel alma oranını artırmak için birden çok ileti fabrikası kullanarak alıcı oluşturun.
  • İstemci tarafı toplu işlemlerinden yararlanmak için zaman uyumsuz işlemleri kullanın.
  • Toplu mağaza erişimini etkin bırakın. Bu erişim, iletilerin kuyruğa yazılma oranını artırır.
  • Bir fabrikanın tüm alıcılarının ön işlem sayısını en yüksek işleme oranlarının 20 katı olarak ayarlayın. Bu sayı, Service Bus istemci protokolü iletimlerinin sayısını azaltır.

Birden çok yüksek aktarım hızı kuyruğu

Hedef: Birden çok kuyruğun genel aktarım hızını en üst düzeye çıkarın. Tek bir kuyruğun aktarım hızı orta veya yüksektir.

Birden çok kuyrukta en yüksek aktarım hızını elde etmek için, tek bir kuyruğun aktarım hızını en üst düzeye çıkarmak için ana hatlarıyla belirtilen ayarları kullanın. Ayrıca, farklı kuyruklardan gönderen veya alan istemciler oluşturmak için farklı fabrikalar kullanın.

Düşük gecikme süresi kuyruğu

Hedef: Kuyruk veya konu başlığının gecikme süresini en aza indirin. Gönderenlerin ve alıcıların sayısı azdır. Kuyruğun aktarım hızı küçük veya orta düzeydedir.

  • İstemci tarafı toplu işlemini devre dışı bırakın. İstemci hemen bir ileti gönderir.
  • Toplu depo erişimini devre dışı bırakın. Hizmet, iletiyi hemen depoya yazar.
  • Tek bir istemci kullanıyorsanız, ön işlem sayısını alıcının işlem hızının 20 katı olarak ayarlayın. Kuyruğa aynı anda birden çok ileti gelirse, Service Bus istemci protokolü bunların tümünü aynı anda iletir. İstemci bir sonraki iletiyi aldığında, bu ileti zaten yerel önbellektedir. Önbellek küçük olmalıdır.
  • Birden çok istemci kullanıyorsanız, prefetch sayısını 0 olarak ayarlayın. Sayıyı ayarlayarak ikinci istemci ikinci iletiyi alabilir ve ilk istemci ilk iletiyi işlemeye devam edebilir.

Çok sayıda gönderen içeren kuyruk

Hedef: Çok sayıda gönderenle bir kuyruğun veya konunun aktarım hızını en üst düzeye çıkarın. Her gönderen, iletileri orta düzeyde bir ücretle gönderir. Alıcı sayısı azdır.

Service Bus, bir mesajlaşma varlığıyla en fazla 1.000 eşzamanlı bağlantı sağlar. Bu sınır ad alanı düzeyinde uygulanır ve kuyruklar, konular veya abonelikler ad alanı başına eş zamanlı bağlantı sınırıyla sınırlanır. Kuyruklar için bu numara gönderenler ve alıcılar arasında paylaşılır. Gönderenler için 1.000 bağlantının tümü gerekiyorsa kuyruğu bir konu başlığı ve tek bir abonelikle değiştirin. Bir konu, gönderenlerden en fazla 1.000 eşzamanlı bağlantı kabul eder. Abonelik, alıcılardan ek 1.000 eşzamanlı bağlantı kabul eder. 1.000'den fazla eşzamanlı gönderen gerekiyorsa, gönderenler HTTP aracılığıyla Service Bus protokolüne ileti göndermelidir.

Aktarım hızını en üst düzeye çıkarmak için şu adımları izleyin:

  • Her gönderen farklı bir işlemdeyse, işlem başına yalnızca tek bir fabrika kullanın.
  • İstemci tarafı toplu işlemlerinden yararlanmak için zaman uyumsuz işlemleri kullanın.
  • Toplu mağaza erişimini etkin bırakın. Bu erişim, iletilerin kuyruğa veya konuya yazılma oranını artırır.
  • Bir fabrikanın tüm alıcılarının ön işlem sayısını en yüksek işleme oranlarının 20 katı olarak ayarlayın. Bu sayı, Service Bus istemci protokolü iletimlerinin sayısını azaltır.

Çok sayıda alıcı içeren kuyruk

Hedef: Çok sayıda alıcısı olan bir kuyruğun veya aboneliğin alma oranını en üst düzeye çıkarın. Her alıcı iletileri orta hızda alır. Gönderenlerin sayısı azdır.

Service Bus, bir varlığa en fazla 1.000 eşzamanlı bağlantı sağlar. Bir kuyruk 1.000'den fazla alıcı gerektiriyorsa kuyruğu bir konu başlığı ve birden çok abonelikle değiştirin. Her abonelik en fazla 1.000 eşzamanlı bağlantıyı destekleyebilir. Alternatif olarak, alıcılar kuyruğa HTTP protokolü aracılığıyla erişebilir.

Aktarım hızını en üst düzeye çıkarmak için şu yönergeleri izleyin:

  • Her alıcı farklı bir işlemdeyse, işlem başına yalnızca tek bir fabrika kullanın.
  • Alıcılar zaman uyumlu veya zaman uyumsuz işlemleri kullanabilir. Tek bir alıcının orta düzeyde alma hızı göz önünde bulundurulduğunda, Bir Complete isteğinin istemci tarafı toplu işlemi alıcı aktarım hızını etkilemez.
  • Toplu mağaza erişimini etkin bırakın. Bu erişim, varlığın genel yükünü azaltır. Ayrıca iletilerin kuyruğa veya konuya yazılma oranını da artırır.
  • Prefetch sayısını küçük bir değere ayarlayın (örneğin, PrefetchCount = 10). Bu sayı, diğer alıcılarda çok sayıda ileti önbelleğe alınmışken alıcıların boşta olmasını engeller.

Birkaç aboneliği olan konu

Hedef: Birkaç abonelikle bir konunun aktarım hızını en üst düzeye çıkarın. Bir ileti birçok abonelik tarafından alınır; bu da tüm aboneliklere göre birleşik alma oranının gönderme hızından daha yüksek olduğu anlamına gelir. Gönderenlerin sayısı azdır. Abonelik başına alıcı sayısı azdır.

Aktarım hızını en üst düzeye çıkarmak için şu yönergeleri izleyin:

  • Konuya genel gönderme oranını artırmak için, gönderen oluşturmak için birden çok ileti fabrikası kullanın. Her gönderen için zaman uyumsuz işlemler veya birden çok iş parçacığı kullanın.
  • Bir abonelikten genel alma oranını artırmak için birden çok ileti fabrikası kullanarak alıcı oluşturun. Her alıcı için zaman uyumsuz işlemler veya birden çok iş parçacığı kullanın.
  • İstemci tarafı toplu işlemlerinden yararlanmak için zaman uyumsuz işlemleri kullanın.
  • Toplu mağaza erişimini etkin bırakın. Bu erişim, iletilerin konuya yazılma oranını artırır.
  • Bir fabrikanın tüm alıcılarının ön işlem sayısını en yüksek işleme oranlarının 20 katı olarak ayarlayın. Bu sayı, Service Bus istemci protokolü iletimlerinin sayısını azaltır.

Çok sayıda aboneliği olan konu

Hedef: Çok sayıda abonelikle bir konunun aktarım hızını en üst düzeye çıkarın. Bir ileti birçok abonelik tarafından alınır; bu da tüm aboneliklere göre birleşik alma oranının gönderme hızından daha yüksek olduğu anlamına gelir. Gönderenlerin sayısı azdır. Abonelik başına alıcı sayısı azdır.

Çok sayıda aboneliğe sahip konular, tüm iletiler tüm aboneliklere yönlendirilirse genellikle düşük bir genel aktarım hızı sunar. Bunun nedeni, her iletinin birçok kez alınması ve bir konudaki tüm iletilerin ve tüm aboneliklerinin aynı depoda depolanmasıdır. Burada, abonelik başına gönderen ve alıcı sayısının az olduğu varsayımı yer alır. Service Bus, konu başına en fazla 2.000 aboneliği destekler.

Aktarım hızını en üst düzeye çıkarmak için aşağıdaki adımları deneyin:

  • İstemci tarafı toplu işlemlerinden yararlanmak için zaman uyumsuz işlemleri kullanın.
  • Toplu mağaza erişimini etkin bırakın. Bu erişim, iletilerin konuya yazılma oranını artırır.
  • Ön koşul sayısını, iletilerin alındığı beklenen oranın 20 katı olarak ayarlayın. Bu sayı, Service Bus istemci protokolü iletimlerinin sayısını azaltır.