Service Bus mesajlaşma kullanarak performans iyileştirmeleri için en iyi uygulamalar

bu makalede, aracılı iletileri değiş tokuş yaparken performansı iyileştirmek için Azure Service Bus 'nin nasıl kullanılacağı açıklanır. Bu makalenin ilk bölümünde, performansı artırmak için farklı mekanizmalar açıklanmıştır. ikinci bölüm, belirli bir senaryoda en iyi performansı sunabileceği şekilde Service Bus kullanımı hakkında rehberlik sağlar.

Bu makale boyunca, "Client" terimi Service Bus erişen herhangi bir varlığa başvurur. Bir istemci, gönderenin veya alıcının rolünü alabilir. "gönderici" terimi, bir Service Bus kuyruğuna veya bir konuya ileti gönderen bir Service Bus kuyruğu istemcisi ya da bir konu istemcisi için kullanılır. "alıcı" terimi, bir Service Bus kuyruğundan veya bir abonelikten ileti alan Service Bus kuyruğu istemci veya abonelik istemcisine başvurur.

Kaynak planlaması ve konuları

teknik kaynak kullanımı gibi, akıllıca planlaması, Azure Service Bus uygulamanızın beklediği performansı sağladığından emin olmak için anahtarıdır. 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ığına ilişkin faktörlerin bir konağına bağlıdır.

Fiyatlandırma katmanı

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

• Standart katman -uygulamaların azaltmasına duyarlı olmayan geliştirici/test ortamları veya düşük aktarım hızı senaryoları için uygundur.

• Premium katmanı , tahmin edilebilir gecikme süresi ve aktarım hızı gerektiren değişen verimlilik gereksinimlerine sahip üretim ortamları için uygundur. ayrıca, Service Bus premium ad alanları otomatik olarak ölçeklendirilebileceğinden , verimlilik halinde ani artışlar sağlamak için etkinleştirilebilir.

Premium için üretilen iş hesaplanıyor

Service Bus gönderilen veriler ikiliye serileştirilir ve alıcı tarafından alındığında seri durumdan çıkarılamaz. bu nedenle, uygulamalar iletileri atomik iş birimi olarak düşünürken, Service Bus aktarım hızını bayt (veya megabayt) olarak ölçer.

aktarım hızı gereksinimini hesaplarken, Service Bus (giriş) ve Service Bus (çıkış) tarafından alınan verilere gönderilen verileri göz önünde bulundurun.

Beklenen şekilde, aktarım hızı birlikte toplanmış küçük ileti yükleri için daha yüksektir.

Karşılaştırmalar

aşağıda, SB ad alanınız için alacağınız beklenen aktarım hızını görmek üzere çalıştırabileceğiniz bir GitHub örneği verilmiştir. Kıyaslama testlerimizdeileti birimi başına YAKLAŞıK 4 MB/sanıye (mu) giriş ve çıkış gözlemliyoruz.

Benchişaretleme örneği herhangi bir Gelişmiş özellik kullanmaz, bu nedenle uygulamalarınızın gözleneceği verimlilik, senaryolarınıza göre farklılık açmış olur.

İşlem değerlendirmeleri

belirli Service Bus özelliklerinin kullanılması, beklenen aktarım hızını azaletkileyebilecek işlem kullanımı gerektirebilir. Bu özelliklerden bazıları-

1. Bağlanabilecek.
2. Tek bir konuda birden çok aboneliğe sahip olmak.
3. Tek bir abonelikte birçok filtre çalıştırılıyor.
4. Zamanlanan iletiler.
5. Ertelenmiş iletiler.
6. Hareket.
7. Yinelenenleri kaldırma & geri arama süresi 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ı almadıysanız, CPU kullanım ölçümlerini gözden geçirebilir ve Service Bus Premium ad alanınızı ölçeklendirdirebilirsiniz.

ayrıca , Service Bus ad alanını otomatik olarak ölçeklendirmekiçin Azure izleyici 'yi de kullanabilirsiniz.

Ad alanları genelinde parçalama

Ad alanına ayrılan Işlem (mesajlaşma birimleri) ölçeklendirilirken daha kolay bir çözümdür ve verimlilik için doğrusal bir artış sunmayabilir . bunun nedeni, aktarım hızını sınırlayan Service Bus iç işlem (depolama, ağ vb.) olabilir.

bu durumda, daha temiz çözüm, varlıklarınızı (kuyruklar ve konular) farklı Service Bus Premium ad alanları genelinde parçalara parçalamaya yönelik olur. Farklı Azure bölgelerindeki farklı ad alanları genelinde parçalı olarak da göz önüne alabilirsiniz.

Protokoller

Service Bus, istemcilerin üç protokolden birini kullanarak ileti göndermesini ve 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)

Service Bus bağlantısını sürdürdüğü için AMQP en verimli yoldur. Toplu işleme ve önceden getirmede uygular. Açıkça belirtilmedikçe, bu makaledeki tüm içerikler AMQP veya SBMP kullanımını varsayar.

uygun Service Bus .net SDK 'sını seçme

bu Azure.Messaging.ServiceBus paket, kasım 2020 itibariyle sunulan en son Azure Service Bus .net SDK 'udur. Kritik hata düzeltmelerini almaya devam edecek iki eski .NET SDK 'Sı vardır, ancak bunun yerine en son SDK 'Yı kullanmanızı önemle öneririz. Eski SDK 'lardan nasıl geçiş yapılacağı hakkındaki ayrıntılar için geçiş kılavuzunu okuyun.

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

Fabrikaları ve istemcileri yeniden kullanma

Aşağıdaki notta tüm SDK 'lar için geçerli olur:

Eş zamanlı işlemler

Gönderme, alma, silme, vb. gibi işlemler, biraz zaman alabilir. bu süre, Service Bus hizmetinin işlemi ve isteğin gecikme süresini ve yanıtı işlemek için aldığı süreyi 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şlemleri zamanlar. Sonraki istek, önceki istek tamamlanmadan önce başlatılır. Aşağıdaki kod parçacığı, zaman uyumsuz gönderme işlemine bir örnektir:

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

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

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

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

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

var sendFirstMessageTask =
    queueClient.SendAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    queueClient.SendAsync(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şlemine bir örnektir.

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

var receiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);

static Task LogErrorAsync(Exception exception)
{
    Console.WriteLine(exception);
    return Task.CompletedTask;
};

receiver.RegisterMessageHandler(
    async (message, cancellationToken) =>
    {
        Console.WriteLine("Handle message");
        await receiver.CompleteAsync(message.SystemProperties.LockToken);
    },
    new MessageHandlerOptions(e => LogErrorAsync(e.Exception))
    {
        AutoComplete = false,
        MaxConcurrentCalls = 20
    });

var factory = MessagingFactory.CreateFromConnectionString(connectionString);
var receiver = await factory.CreateMessageReceiverAsync(queueName, ReceiveMode.PeekLock);

// Register the handler to receive messages asynchronously
receiver.OnMessageAsync(
    async message =>
    {
        Console.WriteLine("Handle message");
        await message.CompleteAsync();
    },
    new OnMessageOptions
    {
        AutoComplete = false,
        MaxConcurrentCalls = 20
    });

Alma modu

Bir kuyruk veya abonelik istemcisi oluştururken, bir alma modu belirtebilirsiniz: Peek-kilitle veya al ve Sil. Varsayılan alma modu PeekLock . Varsayılan modda çalışırken, istemci Service Bus ileti alma isteği gönderir. İstemci iletiyi aldıktan sonra iletiyi tamamlamaya yönelik bir istek gönderir.

Alma modu olarak ayarlandığında ReceiveAndDelete , her iki adım tek bir istekte birleştirilir. Bu adımlar genel işlem sayısını azaltır ve genel ileti işleme hızını iyileştirebilir. Bu performans kazancı, iletileri kaybetme riskiyle gelir.

Service Bus, alma ve silme işlemlerine yönelik işlemleri desteklemez. Ayrıca, istemcinin bir iletiyi erteleme veya atılacak bir ileti almak istediği her senaryo için Peek kilit semantiği gerekir.

İstemci tarafı toplu işleme

İstemci tarafı toplu işleme, bir kuyruk veya konu istemcisinin belirli bir süre için ileti gönderilmesini geciktirmesini sağlar. İstemci bu süre içinde başka iletiler gönderirse, iletileri tek bir toplu iş olarak gönderir. İstemci tarafı toplu işleme Ayrıca bir kuyruk veya abonelik istemcisinin birden çok tamamlanmış isteği tek bir istek halinde toplu olarak yığın oluşturmasına neden olur. Toplu işleme yalnızca zaman uyumsuz gönderme ve Tamamlanan işlemler için kullanılabilir. Zaman uyumlu işlemler hemen Service Bus hizmetine gönderilir. Toplu işleme, göz atma veya alma işlemleri veya istemciler arasında toplu işlem gerçekleşmiyor.

var settings = new MessagingFactorySettings
{
    NetMessagingTransportSettings =
    {
        BatchFlushInterval = TimeSpan.Zero
    }
};
var factory = MessagingFactory.Create(namespaceUri, settings);

Task SendBatchAsync(IEnumerable<BrokeredMessage> messages);

Depo erişimini toplu işleme

bir kuyruğun, konunun veya aboneliğin aktarım hızını artırmak için Service Bus, iç deposuna yazarken birden çok ileti işler.

• Bir kuyrukta toplu işlemeyi etkinleştirdiğinizde, depoya ileti yazma ve depodan ileti silme toplu olarak oluşturulur.
• Bir konu üzerinde toplu işlemeyi etkinleştirdiğinizde, depoya ileti yazmak toplu olarak oluşturulur.
• Bir abonelikte toplu işlemeyi etkinleştirdiğinizde, depodan ileti silme toplu olarak oluşturulur.
• bir varlık için toplu depolama erişimi etkinleştirildiğinde, Service Bus bu varlık için bir mağaza yazma işlemini 20 ms 'ye kadar geciktirir.

Bu Aralık süresince gerçekleşen ek mağaza işlemleri toplu işe eklenir. Toplu depolama erişimi yalnızca gönderme ve tamamlanma işlemlerini etkiler; alma işlemleri etkilenmez. Toplu depo erişimi, bir varlık üzerindeki bir özelliktir. Toplu işleme, toplu depo erişimini etkinleştiren tüm varlıklarda oluşur.

Yeni bir kuyruk, konu veya abonelik oluştururken, toplu mağaza erişimi varsayılan olarak etkindir.

var options = new CreateQueueOptions(path)
{
    EnableBatchedOperations = false
};
var queue = await administrationClient.CreateQueueAsync(options);

var queueDescription = new QueueDescription(path)
{
    EnableBatchedOperations = false
};
var queue = await managementClient.CreateQueueAsync(queueDescription);

var queueDescription = new QueueDescription(path)
{
    EnableBatchedOperations = false
};
var queue = namespaceManager.CreateQueue(queueDescription);

Toplu depo erişimi, faturalandırılabilir mesajlaşma işlemlerinin sayısını etkilemez. Bu, bir kuyruğun, konunun veya aboneliğin bir özelliğidir. İstemci ile hizmet arasında kullanılan alma modundan ve protokolden bağımsız Service Bus.

Önyükle

Önceden alma, kuyruk veya abonelik istemcisinin iletileri aldığında hizmetten ek iletiler yüklemesini sağlar. İstemci bu iletileri yerel önbellekte depolar. Önbelleğin boyutu veya özellikleri tarafından QueueClient.PrefetchCount SubscriptionClient.PrefetchCount belirlenir. Önceden karara varmasına olanak sağlayan her istemci kendi önbelleğini sürdürür. Önbellek istemciler arasında paylaşılmaz. İstemci bir alma işlemi başlatırsa ve önbelleği boşsa hizmet toplu ileti iletir. Toplu iş boyutu önbelleğin boyutuna veya 256 KB'a eşittir (hangisi daha küçükse). İstemci bir alma işlemi başlatırsa ve önbellek bir ileti içeriyorsa, ileti önbellekten alınır.

Bir ileti önceden geldiğinde, hizmet önceden iletiyi kilitler. Kilit ile önceden alınan ileti farklı bir alıcı tarafından alınamamıştır. Kilit süresi dolmadan önce alıcı iletiyi tamamlayamazsa, ileti diğer alıcılar tarafından kullanılabilir hale gelir. İletinin önceden alınmış kopyası önbellekte kalır. Süresi dolan önbelleğe alınmış kopyayı tüketen alıcı, 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 dakika uzatılabilir. Süresi dolan iletilerin tüketimini önlemek için önbellek boyutunu bir istemcinin kilit zaman aşımı aralığı içinde tükettiği ileti sayısından küçük olarak ayarlayın.

60 saniyelik varsayılan kilit süre sonu kullanılırken, için iyi bir değer, fabrikanın tüm alıcılarının en yüksek işleme oranlarının PrefetchCount 20 katıdır. Örneğin, bir fabrika üç alıcı oluşturur ve her alıcı saniye başına 10 adede kadar 10 alıcının işlemini tamamlar. Önceden sipariş sayısı 20 X 3 X 10 = 600'ü aşmamalı. Varsayılan PrefetchCount olarak, 0 olarak ayarlanır; başka bir şey hizmetten başka ileti getirilmez.

İletileri önceden alma, ileti işlemlerinin veya gidiş dönüşlerin toplam sayısını azaltan bir kuyruk veya abonelik için genel aktarım hızını artırır. Ancak ilk iletiyi getirmek daha uzun sürer (artan ileti boyutu nedeniyle). Bu iletiler istemci tarafından zaten indirilmiş olduğundan, önbellekten önceden alınmış iletileri alma daha hızlı olacaktır.

İletinin yaşam süresi (TTL) özelliği, sunucunun iletiyi istemciye gönderdiği sırada sunucu tarafından denetlenir. İstemci, ileti alınca iletinin TTL özelliğini denetlemez. Bunun yerine, ileti istemci tarafından önbelleğe alınmışken iletinin TTL değeri geçmiş olsa bile ileti alınabilirsiniz.

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

Önceden Alma ve ReceiveBatch

Birden çok küme önceden gönderme kavramları, iletileri toplu olarak işlemeye benzer semantiklere sahipken ( ) bu yaklaşımları birlikte kullanırken göz altında tutulması gereken bazı küçük ReceiveBatch farklılıklar vardır.

Önceden sipariş, istemcide (ve ) bir yapılandırma (veya mod) ve bir işlemdir QueueClient SubscriptionClient ReceiveBatch (istek-yanıt semantiğine sahip).

Bu yaklaşımları birlikte kullanırken aşağıdaki örnekleri göz önünde bulunduralım:

• Önceden alma, 'den almayı bekliyorsanız ileti sayısından büyük veya bu sayıya eşit ReceiveBatch olabilir.
• Önceden işleme, saniye başına işlenen ileti sayısının n/3 katı olabilir; burada n varsayılan kilit süresidir.

Doyumsuz bir yaklaşıma sahip olma konusunda bazı zorluklar vardır; diğer bir nedenle, önceden alma sayısını yüksek tutmak, iletinin belirli bir alıcıya kilitlenmiş olduğunu gösterir. Yukarıda belirtilen eşikler arasında değerleri önceden belirlemeyi ve neyin uygun olduğunu ampirik olarak tanımlamayı önerin.

Birden çok kuyruk

Tek bir kuyruk veya konu başlığı bekleneni işleyene kadar 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.

Geliştirme ve test özellikleri

Service Bus, özellikle geliştirme için kullanılan ve üretim yapılandırmalarında asla kullanılmama gereken bir özelik içerir: TopicDescription.EnableFilteringMessagesBeforePublishing .

Konuya yeni kurallar veya filtreler ekleniyorsa, yeni filtre ifadesinin beklendiği gibi TopicDescription.EnableFilteringMessagesBeforePublishing çalıştığını doğrulamak için kullanabilirsiniz.

Senaryolar

Aşağıdaki bölümlerde tipik mesajlaşma senaryoları açıklanmaktadır ve tercih edilen mesajlaşma Service Bus özetlemelidir. Aktarım hızı küçük (1 ileti/saniyenin altında), orta (1 ileti/saniye veya daha büyük ama 100 ileti/saniyenin altında) ve yüksek (100 ileti/saniye veya daha yüksek) olarak sınıflandırılır. İstemci sayısı küçük (5 veya daha az), orta (5'ten fazla ama 20'ye eşit veya daha küçük) 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 çıkarma. Gönderen ve alıcı sayısı azdır.

• Kuyruğa genel gönderme oranını artırmak için, gönderenleri 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 alıcı oluşturmak üzere birden çok ileti fabrikası kullanın.
• İstemci tarafı toplu işlemeden yararlanmak için zaman uyumsuz işlemleri kullanın.
• İstemci protokolü aktarımlarının sayısını azaltmak için toplu işlem aralığını 50 ms Service Bus ayarlayın. Birden çok gönderen kullanılıyorsa, toplu işlem aralığını 100 ms olarak artır.
• Toplu depo erişimini etkin bırakın. Bu erişim, iletilerin kuyruğa yazıldığı genel oranı artırır.
• Bir fabrikanın tüm alıcılarının en yüksek işleme oranlarının 20 katı olarak önceden alma sayısını ayarlayın. Bu sayı, istemci protokolü Service Bus 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 çıkarma. Tek bir kuyruğun aktarım hızı orta veya yüksek.

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 üzere özetlenen ayarları kullanın. Ayrıca, farklı kuyruklardan gelen veya gelen istemciler oluşturmak için farklı fabrikalar kullanın.

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

Hedef: Bir kuyruğun veya konunun gecikme süresini en aza indirme. Gönderen ve alıcı sayısı azdır. Kuyruğun aktarım hızı küçük veya orta düzeydedir.

• İstemci tarafı toplu işlemi devre dışı bırakma. İstemci hemen bir ileti gönderir.
• Toplu depo erişimini devre dışı bırakma. Hizmet iletiyi hemen depoya yazar.
• Tek bir istemci kullanıyorsanız, ön alma sayısını alıcının işleme oranının 20 katı olarak ayarlayın. Kuyruğa aynı anda birden fazla ileti Service Bus istemci protokolü bunları aynı anda iletir. İstemci bir sonraki iletiyi aldığında, bu ileti zaten yerel önbellektedir. Önbellek küçük olması gerekir.
• Birden çok istemci kullanıyorsanız, önceden ayarlama sayısını 0 olarak ayarlayın. Sayı ayar tarafından, ilk istemci ilk iletiyi işlemeye devam ederken ikinci istemci ikinci iletiyi alabilirsiniz.

Çok sayıda gönderen ile kuyruk

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

Service Bus mesajlaşma varlığa en fazla 1000 eş zamanlı bağlantı sağlar. Bu sınır ad alanı düzeyinde uygulanır ve kuyruklar, konu başlıkları veya abonelikler ad alanı başına eş zamanlı bağlantı sınırına göre sınırlandırıldı. Kuyruklar için bu sayı gönderenler ve alıcılar arasında paylaşılır. Gönderenler için 1000 bağlantının hepsi gerekli ise kuyruğu bir konu başlığı ve tek bir abonelikle değiştirin. Bir konu, gönderenlerden en fazla 1000 eş zamanlı bağlantı kabul eder. Abonelik, alıcılardan gelen ek 1000 eş zamanlı bağlantı kabul eder. 1000'den fazla eş zamanlı gönderen gerekli ise, gönderenler HTTP üzerinden Service Bus protokole ileti göndermeleri gerekir.

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

• Her gönderen farklı bir işlemde ise, işlem başına yalnızca tek bir fabrika kullanın.
• İstemci tarafı toplu işlemeden yararlanmak için zaman uyumsuz işlemleri kullanın.
• İstemci protokolü aktarımlarının sayısını azaltmak için varsayılan toplu işlem aralığı olan 20 ms'Service Bus kullanın.
• Toplu depo erişimini etkin bırakın. Bu erişim, iletilerin kuyruğa veya konuya yazıldığı genel hızı artırır.
• Bir fabrikanın tüm alıcılarının en yüksek işleme oranlarının 20 katı olarak önceden alma sayısını ayarlayın. Bu sayı, istemci protokolü Service Bus sayısını azaltır.

Çok sayıda alıcı ile kuyruk

Hedef: Çok sayıda alıcıyla bir kuyruğun veya aboneliğin alma oranını en üst düzeye çıkarma. Her alıcı iletileri orta oranda alır. Gönderen sayısı azdır.

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

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

• Her alıcı farklı bir işlemde ise, işlem başına yalnızca tek bir fabrika kullanın.
• Alıcılar zaman uyumlu veya zaman uyumsuz işlemler kullanabilir. Tek bir alıcının orta alma oranına göre, Tamamlama isteğinin istemci tarafı toplu işlemesi alıcı aktarım hızını etkilemez.
• Toplu depo 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ıldığı genel oranı da azaltır.
• Önceden ayarlama sayısını küçük bir değere ayarlayın (örneğin, PrefetchCount = 10). Bu sayı alıcıların boşta kalmasını ve diğer alıcıların önbelleğe alınmış çok sayıda iletiye sahip olduğunu gösterir.

Birkaç aboneliği olan konu

Hedef: Birkaç abonelikle bir konunun aktarım hızını en üst düzeye çıkarma. İleti birçok abonelik tarafından alınmıştır ve bu da tüm aboneliklerde birleşik alma oranının gönderme oranından daha yüksek olduğu anlamına gelir. Gönderen 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önderenleri 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 alıcı oluşturmak üzere birden çok ileti fabrikası kullanın. Her alıcı için zaman uyumsuz işlemler veya birden çok iş parçacığı kullanın.
• İstemci tarafı toplu işlemeden yararlanmak için zaman uyumsuz işlemleri kullanın.
• İstemci protokolü aktarımlarının sayısını azaltmak için varsayılan toplu işlem aralığı olan 20 ms'Service Bus kullanın.
• Toplu depo erişimini etkin bırakın. Bu erişim, iletilerin konu başlığına yazılama oranını artırır.
• Bir fabrikanın tüm alıcılarının en yüksek işleme oranlarının 20 katı olarak önceden alma sayısını ayarlayın. Bu sayı, istemci protokolü Service Bus 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 çıkarma. İleti birçok abonelik tarafından alınmıştır ve bu da tüm aboneliklerde birleşik alma oranının gönderme oranından çok daha yüksek olduğu anlamına gelir. Gönderen sayısı azdır. Abonelik başına alıcı sayısı azdır.

Çok sayıda aboneliği olan konu başlıkları, tüm iletiler tüm aboneliklere yönlendirilmesi durumuyla genellikle düşük bir genel aktarım hızını ortaya çıkarır. Bunun nedeni her iletinin birçok kez alınarak bir konu başlığı ve tüm aboneliklerin aynı depoda depolanmış olmasıdır. Burada, gönderenlerin ve abonelik başına alıcı sayısının az olduğu varsayımı yer almaktadı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şlemeden yararlanmak için zaman uyumsuz işlemleri kullanın.
• İstemci protokolü aktarımlarının sayısını azaltmak için varsayılan toplu işlem aralığı olan 20 ms'Service Bus kullanın.
• Toplu depo erişimini etkin bırakın. Bu erişim, iletilerin konu başlığına yazılama oranını artırır.
• Önceden alma sayısını saniyeler içinde beklenen alma oranının 20 katı olarak ayarlayın. Bu sayı, istemci protokolü Service Bus sayısını azaltır.