osvědčené postupy pro zlepšení výkonu pomocí Service Bus zasílání zpráv

tento článek popisuje, jak pomocí služby Azure Service Bus optimalizovat výkon při výměně zprostředkovaných zpráv. První část tohoto článku popisuje různé mechanismy pro zvýšení výkonu. druhá část poskytuje pokyny k používání Service Bus způsobem, který může nabízet nejlepší výkon v daném scénáři.

V rámci tohoto článku pojem "klient" odkazuje na libovolnou entitu, která přistupuje k Service Bus. Klient může převzít roli odesilatele nebo příjemce. termín "odesilatel" se používá pro klienta Service Bus fronty nebo pro klienta tématu, který odesílá zprávy do fronty Service Bus nebo tématu. pojem "příjemce" odkazuje na klienta Service Bus queue nebo předplatného, který přijímá zprávy z fronty Service Bus nebo z předplatného.

Plánování a požadavky prostředků

stejně jako u jakéhokoli technického reorganizaci je obezřetným plánováním klíč, který zajišťuje, že Azure Service Bus poskytuje výkon, který vaše aplikace očekává. správná konfigurace nebo topologie pro vaše Service Bus obory názvů závisí na hostiteli faktorů, které se týkají vaší architektury aplikace a na tom, jak se používají jednotlivé funkce Service Bus.

Cenová úroveň

Service Bus nabízí různé cenové úrovně. Doporučuje se vybrat odpovídající vrstvu pro požadavky vaší aplikace.

• Úroveň Standard pro vývojářské/testovací prostředí nebo pro scénáře s nízkou propustností, kde aplikace nejsou citlivé na omezování.

• Premium úroveň pro produkční prostředí s proměnlivými nároky na propustnost, při které je potřeba předvídatelné latence a propustnost. Service Bus obory názvů premium se navíc dají automaticky škálovat a dají se povolit pro přizpůsobení špiček v propustnosti.

Výpočet propustnosti pro Premium

Data odesílaná do Service Bus jsou serializovaná do binárního souboru a pak deserializovat při přijetí příjemcem. proto zatímco aplikace považují zprávy za atomické pracovní jednotky, Service Bus míry propustnosti v bajtech (nebo megabajtech).

při výpočtu požadavků na propustnost zvažte data, která se odesílají do Service Bus (příchozí přenos dat), a data přijatá z Service Bus (odchozí).

Jak bylo očekáváno, propustnost je vyšší pro menší datové vytížení zpráv, které lze dávkovat hromadně.

Srovnávací testy

tady je GitHub ukázka , kterou můžete spustit, abyste viděli očekávanou propustnost, kterou obdržíte pro svůj obor názvů SB. V testech srovnávacích testůjsme zjistili přibližně 4 MB/s na jednotku zasílání zpráv (mí) pro příchozí a odchozí přenosy.

Ukázka srovnávacích testů nepoužívá žádné pokročilé funkce, takže propustnost vašich aplikací se liší v závislosti na vašich scénářích.

Požadavky na výpočetní prostředky

použití některých funkcí Service Bus může vyžadovat výpočetní využití, které může snížit očekávanou propustnost. Některé z těchto funkcí jsou:

1. Rušování.
2. Fanning se na několik předplatných v jednom tématu.
3. Spouštění mnoha filtrů v rámci jednoho předplatného.
4. Naplánované zprávy.
5. Odložené zprávy.
6. Převody.
7. Zrušení duplicity & zobrazení časového intervalu pro hledání.
8. Vpřed na (předání od jedné entity k druhému).

pokud vaše aplikace využívá některou z výše uvedených funkcí a nepřijímáte očekávanou propustnost, můžete zkontrolovat metriky využití CPU a zvážit horizontální navýšení kapacity Service Bus Premium oboru názvů.

můžete také využít Azure Monitor k automatickému škálování oboru názvů Service Bus.

Horizontálního dělení napříč obory názvů

Při škálování výpočetních prostředků (jednotky zasílání zpráv), které jsou přiděleny oboru názvů, je jednodušší řešení, ale nemusí poskytovat lineární nárůst propustnosti. důvodem je Service Bus interních (úložišť, sítí atd.), což může omezit propustnost.

řešením čištění v tomto případě je horizontálních oddílů své entity (fronty a témata) napříč různými obory názvů Premium Service Bus. V různých oblastech Azure můžete také zvážit horizontálního dělení napříč různými obory názvů.

Protokoly

Service Bus umožňuje klientům odesílat a přijímat zprávy prostřednictvím jednoho ze tří protokolů:

1. Rozšířený protokol řízení front zpráv (AMQP)
2. Service Bus Protokol zasílání zpráv (SBMP)
3. Hypertextový přenosový protokol (HTTP)

AMQP je nejúčinnější, protože udržuje připojení k Service Bus. Implementuje také dávkování a předběžné načítání. Pokud není výslovně uvedeno jinak, veškerý obsah v tomto článku předpokládá použití AMQP nebo SBMP.

výběr vhodné Service Bus .net SDK

Azure.Messaging.ServiceBusbalíček je nejnovější sada Azure Service Bus .net SDK dostupná od listopadu 2020. Existují dvě starší sady SDK sady .NET, které budou nadále získávat kritické opravy chyb, ale důrazně doporučujeme místo toho použít nejnovější sadu SDK. Podrobnosti o tom, jak přejít ze starších sad SDK, najdete v Průvodci migrací .

Další informace o minimální podpoře .NET Standard platforem najdete v tématu Podpora implementace rozhraní .NET.

Používání továrn a klientů

Následující Poznámka platí pro všechny sady SDK:

Souběžné operace

Operace, jako je například Send, Receive, DELETE atd., nějakou dobu trvá. tato doba zahrnuje dobu, kterou služba Service Bus potřebuje k zpracování operace, a latenci žádosti a odpovědi. Chcete-li zvýšit počet operací v čase, operace musí být spuštěny souběžně.

Klient plánuje souběžné operace provedením asynchronních operací. Další požadavek se spustí před dokončením předchozí žádosti. Následující fragment kódu je příkladem asynchronní operace odeslání:

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

Následující kód je příkladem asynchronní operace Receive.

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

Režim příjmu

Když vytváříte klienta front nebo odběrů, můžete zadat režim přijímání: prohlížet a uzamknout nebo přijmout a odstranit. Výchozí režim příjmu je PeekLock . Při provozu ve výchozím režimu pošle klient žádost o přijetí zprávy od Service Bus. Jakmile klient obdrží zprávu, pošle požadavek na dokončení zprávy.

Při nastavení režimu příjmu na ReceiveAndDelete je oba kroky kombinovány v jednom požadavku. Tyto kroky omezují celkový počet operací a můžou zlepšit celkovou propustnost zpráv. Tento zvýšení výkonu přináší riziko ztráty zpráv.

Service Bus nepodporuje transakce pro operace receive a delete. U všech scénářů, ve kterých bude klient chtít zprávu odložit nebo nedoručeně , se vyžaduje taky sémantika prohlížení zámku.

Dávkování na straně klienta

Dávkování na straně klienta umožňuje klientovi nebo tématu klienta zpozdit odeslání zprávy po určitou dobu. Pokud během tohoto časového období klient odešle další zprávy, přenese zprávy v jedné dávce. Dávkování na straně klienta také způsobí, že klient fronty nebo předplatného vygeneruje více úplných požadavků do jediného požadavku. Dávkování je k dispozici pouze pro operace asynchronního odeslání a dokončení . Synchronní operace se okamžitě odesílají do služby Service Bus. K dávkování nedochází při operacích prohlížení a příjmu, ani k dávkování mezi klienty.

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

Task SendBatchAsync(IEnumerable<BrokeredMessage> messages);

Batch – přístup k úložišti

pokud chcete zvýšit propustnost fronty, tématu nebo předplatného, Service Bus se při zápisu do svého interního úložiště dávky vyřadí několik zpráv.

• Když povolíte dávkování ve frontě, zapisuje se zprávy do úložiště a odstraňují se zprávy ze Storu, budou v dávce.
• Když povolíte dávkování pro téma, zapisuje se do úložiště zprávy.
• Když povolíte dávkování v rámci předplatného, budou se odstraňovat zprávy ze Storu.
• když je pro entitu povolený přístup k dávkovému ukládání, Service Bus zpozdí operaci zápisu úložiště pro tuto entitu až o 20 ms.

Další operace úložiště, ke kterým dojde během tohoto intervalu, se přidají do dávky. Přístup k dávkovému úložišti má vliv jenom na operace Send a Complete . operace přijímání nejsou ovlivněny. Přístup k Batch Storu je vlastnost v entitě. Dávkování probíhá napříč všemi entitami, které umožňují přístup k dávce v dávkovém úložišti.

Při vytváření nové fronty, tématu nebo předplatného je ve výchozím nastavení povolený přístup k Batch Storu.

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

Přístup k Batch Storu nemá vliv na počet fakturovatelných operací zasílání zpráv. Jedná se o vlastnost fronty, tématu nebo předplatného. Je nezávislý na režimu příjmu a protokolu, který se používá mezi klientem a Service Bus službou.

Prefetching

Předběžné načtení umožňuje klientovi fronty nebo odběru načíst další zprávy ze služby při přijetí zpráv. Klient ukládá tyto zprávy do místní mezipaměti. Velikost mezipaměti je určena vlastnostmi QueueClient.PrefetchCount SubscriptionClient.PrefetchCount nebo . Každý klient, který umožňuje předběžné načtení, udržuje svou vlastní mezipaměť. Mezipaměť není sdílena mezi klienty. Pokud klient spustí operaci příjmu a jeho mezipaměť je prázdná, služba odešle dávku zpráv. Velikost dávky se rovná velikosti mezipaměti nebo 256 kB podle toho, která je menší. Pokud klient spustí operaci příjmu a mezipaměť obsahuje zprávu, zpráva se pojí z mezipaměti.

Při předběžném načtení zprávy služba předem načtenou zprávu zamkne. Se zámkem nemůže předem načtenou zprávu získat jiný příjemce. Pokud příjemce zprávu nemůže dokončit před vypršením platnosti zámku, zpráva bude dostupná ostatním příjemcům. Předem načtená kopie zprávy zůstane v mezipaměti. Příjemce, který využívá kopii v mezipaměti s vypršenou platností, obdrží při pokusu o dokončení této zprávy výjimku. Ve výchozím nastavení platnost zámku zprávy vyprší po 60 sekundách. Tato hodnota se může prodloužit na 5 minut. Pokud chcete zabránit používání zpráv, jejichž platnost vypršela, nastavte velikost mezipaměti menší, než je počet zpráv, které může klient během časového limitu uzamčení spotřebovat.

Při použití výchozího vypršení platnosti zámku 60 sekund je dobrou hodnotou 20krát maximální rychlost zpracování všech příjemců PrefetchCount továrny. Továrna například vytvoří tři příjemce a každý příjemce může zpracovat až 10 zpráv za sekundu. Počet předběžného načtení by neměl překročit 20 × 3 × 10 = 600. Ve výchozím nastavení PrefetchCount je hodnota nastavená na 0, což znamená, že se ze služby načítou žádné další zprávy.

Předběžné načtení zpráv zvyšuje celkovou propustnost fronty nebo odběru, protože snižuje celkový počet operací se zprávami nebo dobu round trip. Načtení první zprávy ale bude trvat déle (kvůli zvětšené velikosti zprávy). Příjem předem načtených zpráv z mezipaměti bude rychlejší, protože tyto zprávy už klient stáhl.

Server kontroluje vlastnost TTL (Time to Live) zprávy v době, kdy server odešle zprávu klientovi. Klient při přijetí zprávy neschová vlastnost hodnoty TTL zprávy. Místo toho může být zpráva přijata i v případě, že během ukládání zprávy do mezipaměti klientem uplynula TTL zprávy.

Předběžné načtení nemá vliv na počet fakturovatelných operací zasílání zpráv a je k dispozici pouze pro Service Bus protokolu klienta. Protokol HTTP nepodporuje předběžné načtení. Předběžné načtení je k dispozici pro synchronní i asynchronní operace příjmu.

Předběžné načtení a ReceiveBatch

I když koncepty předběžného načtení více zpráv dohromady mají podobnou sémantiku jako zpracování zpráv v dávce ( ), existuje několik drobných rozdílů, které je při použití těchto přístupů nutné mít na paměti ReceiveBatch společně.

Předběžné načtení je konfigurace (nebo režim) na klientovi ( a ) a je operace (která má QueueClient SubscriptionClient ReceiveBatch sémantiku požadavku a odpovědi).

Při společném používání těchto přístupů zvažte následující případy:

• Předběžné načtení by mělo být větší nebo rovno počtu zpráv, které očekáváte od ReceiveBatch .
• Předběžné načtení může být až n/3krát více než n/3krát počet zpráv zpracovaných za sekundu, kde n je výchozí doba trvání zámku.

Existuje několik problémů s používáním greedy přístupu, to znamená udržování vysokého počtu předběžného načtení, protože to znamená, že zpráva je uzamčená na konkrétního příjemce. Doporučujeme vyzkoušet předběžné načtení hodnot mezi výše uvedenými prahovými hodnotami a empiricky určit, co odpovídá.

Více front

Pokud jedna fronta nebo téma nezvládá očekávané chování, použijte více entit zasílání zpráv. Pokud používáte více entit, vytvořte pro každou entitu vyhrazeného klienta místo použití stejného klienta pro všechny entity.

Funkce pro vývoj a testování

Service Bus má jednu funkci, která se používá speciálně pro vývoj a která by se nikdy neměla používat v produkčních konfiguracích: TopicDescription.EnableFilteringMessagesBeforePublishing .

Když do tématu přidáte nová pravidla nebo filtry, můžete použít k ověření, že nový výraz filtru TopicDescription.EnableFilteringMessagesBeforePublishing funguje podle očekávání.

Scénáře

Následující části popisují typické scénáře zasílání zpráv a popisují upřednostňovaná nastavení Service Bus zpráv. Míra propustnosti je klasifikovaná jako malá (méně než 1 zpráva za sekundu), střední (1 zpráva za sekundu nebo větší, ale méně než 100 zpráv za sekundu) a vysoká (100 zpráv za sekundu nebo vyšší). Počet klientů je klasifikovaný jako malý (5 nebo méně), střední (více než 5, ale menší než nebo rovno 20) a velký (více než 20).

Fronta s vysokou propustností

Cíl: Maximalizujte propustnost jedné fronty. Počet odesílatelů a příjemců je malý.

• Pokud chcete zvýšit celkovou rychlost odesílání do fronty, vytvořte odesílatele pomocí několika továren zpráv. Pro každého odesílatele použijte asynchronní operace nebo více vláken.
• Pokud chcete zvýšit celkovou míru příjmu z fronty, vytvořte příjemce pomocí několika továren zpráv.
• Využijte výhod dávkování na straně klienta pomocí asynchronních operací.
• Nastavte interval dávkování na 50 ms, aby se snížil počet Service Bus přenosů klientských protokolů. Pokud se používá více odesílatelů, zvyšte interval dávkování na 100 ms.
• Ponechte povolený dávkový přístup k obchodu. Tento přístup zvyšuje celkovou rychlost zápisu zpráv do fronty.
• Nastavte počet předběžného načtení na 20krát maximální rychlost zpracování všech příjemců továrny. Tento počet snižuje počet přenosů Service Bus klientských protokolů.

Několik front s vysokou propustností

Cíl: Maximalizujte celkovou propustnost více front. Propustnost jednotlivých front je střední nebo vysoká.

Pokud chcete dosáhnout maximální propustnosti napříč více frontami, použijte nastavení uvedená k maximalizaci propustnosti jedné fronty. Pomocí různých továren můžete také vytvářet klienty, kteří odesílají nebo přijímají z různých front.

Fronta s nízkou latencí

Cíl: Minimalizujte latenci fronty nebo tématu. Počet odesílatelů a příjemců je malý. Propustnost fronty je malá nebo střední.

• Zakažte dávkování na straně klienta. Klient okamžitě odešle zprávu.
• Zakažte dávkový přístup k obchodu. Služba okamžitě zapíše zprávu do úložiště.
• Pokud používáte jednoho klienta, nastavte počet předběžného načtení na 20krát rychlost zpracování příjemce. Pokud je do fronty doručeno více zpráv současně, Service Bus klientský protokol je přenáší všechny najednou. Když klient obdrží další zprávu, tato zpráva už je v místní mezipaměti. Mezipaměť by měla být malá.
• Pokud používáte více klientů, nastavte počet předběžného načtení na 0. Nastavením počtu může druhý klient přijmout druhou zprávu, zatímco první klient stále zpracovává první zprávu.

Fronta s velkým počtem odesílatelů

Cíl: Maximalizujte propustnost fronty nebo tématu s velkým počtem odesílatelů. Každý odesílatel odesílá zprávy se střední rychlostí. Počet příjemců je malý.

Service Bus umožňuje až 1 000 souběžných připojení k entitě zasílání zpráv. Toto omezení se vynucuje na úrovni oboru názvů a fronty, témata nebo odběry jsou omezovány limitem souběžných připojení na obor názvů. U front se toto číslo sdílí mezi odesílateli a příjemci. Pokud se pro odesílatele vyžaduje všech 1 000 připojení, nahraďte frontu tématem a jedním odběrem. Téma přijímá až 1 000 souběžných připojení od odesílatelů. Předplatné přijímá další 1000 souběžných připojení od přijímačů. pokud potřebujete více než 1000 současných odesílatelů, odesílají odesílatelé zprávy do protokolu Service Bus přes HTTP.

K maximalizaci propustnosti použijte následující postup:

• Pokud je každý odesilatel v jiném procesu, použijte pro každý proces jenom jeden objekt factory.
• Pomocí asynchronních operací můžete využít dávkování na straně klienta.
• snižte počet Service Busch přenosů klientských protokolů pomocí výchozího intervalu dávkování 20 ms.
• Nechte povolený přístup k Batch Storu. Tento přístup zvyšuje celkovou rychlost, kterou lze zprávy zapsat do fronty nebo tématu.
• Nastavte počet předběžných hodnot na 20 časů, který bude mít maximální počet zpracování všech přijímačů továrny. tento počet snižuje počet Service Busch přenosů klientských protokolů.

Zařazení do fronty s velkým počtem přijímačů

Cíl: Maximalizujte míru přijetí fronty nebo předplatného s velkým počtem přijímačů. Každý příjemce obdrží zprávy se střední sazbou. Počet odesílatelů je malý.

Service Bus povoluje až 1000 souběžných připojení k entitě. Pokud fronta vyžaduje více než 1000 přijímačů, nahraďte frontu tématem a několika odběry. Každé předplatné může podporovat až 1000 souběžných připojení. Přijímačé taky můžou ke frontě přistupovat přes protokol HTTP.

Pokud chcete maximalizovat propustnost, postupujte podle těchto pokynů:

• Pokud je každý příjemce v jiném procesu, použijte pro každý proces jenom jeden objekt factory.
• Přijímačé můžou používat synchronní nebo asynchronní operace. Vzhledem k střední míře příjmu jednotlivého přijímače dávka na straně klienta s úplným požadavkem neovlivní propustnost přijímače.
• Nechte povolený přístup k Batch Storu. Tento přístup omezuje celkové zatížení entity. Zároveň se tím snižuje celková rychlost, kterou lze zprávy zapsat do fronty nebo tématu.
• Nastavte počet předběžných hodnot na malou hodnotu (například PrefetchCount = 10). Tento počet brání přijímačům v nečinnosti, zatímco ostatní příjemci mají velký počet zpráv uložených v mezipaměti.

Téma s několika předplatnými

Cíl: maximalizace propustnosti tématu s několika předplatnými. Celá řada předplatných obdrží zprávu, což znamená, že celková míra příjmu u všech předplatných je větší než rychlost odesílání. Počet odesílatelů je malý. Počet přijímačů na předplatné je malý.

Pokud chcete maximalizovat propustnost, postupujte podle těchto pokynů:

• Pro zvýšení celkové míry odeslání do tématu použijte k vytvoření odesílatelů více tovární zpráv. Pro každého odesilatele použijte asynchronní operace nebo více vláken.
• Pro zvýšení celkové míry příjmu z předplatného použijte k vytvoření přijímačů více zpráv. Pro každého příjemce použijte asynchronní operace nebo více vláken.
• Pomocí asynchronních operací můžete využít dávkování na straně klienta.
• snižte počet Service Busch přenosů klientských protokolů pomocí výchozího intervalu dávkování 20 ms.
• Nechte povolený přístup k Batch Storu. Tento přístup zvyšuje celkovou rychlost, kterou lze do tématu zapsat zprávy.
• Nastavte počet předběžných hodnot na 20 časů, který bude mít maximální počet zpracování všech přijímačů továrny. tento počet snižuje počet Service Busch přenosů klientských protokolů.

Téma s velkým počtem předplatných

Cíl: maximalizace propustnosti tématu s velkým počtem předplatných. Celá řada předplatných obdrží zprávu, což znamená, že celková míra příjmu u všech předplatných je mnohem větší než rychlost odesílání. Počet odesílatelů je malý. Počet přijímačů na předplatné je malý.

Témata s velkým počtem předplatných obvykle zveřejňují nízkou celkovou propustnost, pokud jsou všechny zprávy směrovány do všech předplatných. Je to proto, že každá zpráva je přijata mnohokrát a všechny zprávy v tématu a všechny její odběry jsou uloženy ve stejném úložišti. Předpokladem je, že počet odesílatelů a počet příjemců na předplatné je malý. Service Bus podporuje až 2 000 předplatných na jedno téma.

Pokud chcete maximalizovat propustnost, zkuste provést následující kroky:

• Pomocí asynchronních operací můžete využít dávkování na straně klienta.
• snižte počet Service Busch přenosů klientských protokolů pomocí výchozího intervalu dávkování 20 ms.
• Nechte povolený přístup k Batch Storu. Tento přístup zvyšuje celkovou rychlost, kterou lze do tématu zapsat zprávy.
• Nastavte počet předplatných na hodnotu 20 časů očekávané míry příjmu v sekundách. tento počet snižuje počet Service Busch přenosů klientských protokolů.