Sdílet prostřednictvím

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

  • Článek

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 obsahuje pokyny k používání služby Service Bus způsobem, který v daném scénáři nabízí nejlepší výkon.

V tomto článku pojem "klient" odkazuje na libovolnou entitu, která přistupuje ke službě Service Bus. Klient může převzít roli odesílatele nebo příjemce. Termín "sender" se používá pro klienta fronty služby Service Bus nebo klienta tématu, který odesílá zprávy do fronty služby Service Bus nebo tématu. Termín "příjemce" odkazuje na klienta fronty služby Service Bus nebo klienta předplatného, který přijímá zprávy z fronty služby Service Bus nebo odběru.

Plánování a aspekty zdrojů

Stejně jako u jakýchkoli technických prostředků je obezřetné plánování klíčem k zajištění toho, aby služba Azure Service Bus poskytovala výkon, který vaše aplikace očekává. Správná konfigurace nebo topologie pro obory názvů služby Service Bus závisí na řadu faktorů zahrnujících architekturu vaší aplikace a způsob použití jednotlivých funkcí služby Service Bus.

Cenová úroveň

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

  • Úroveň Standard – Vhodná pro vývojová/testovací prostředí nebo scénáře s nízkou propustností, ve kterých nejsou aplikace citlivé na omezování.

  • Úroveň Premium – Vhodná pro produkční prostředí s různými požadavky na propustnost, kde se vyžaduje předvídatelná latence a propustnost. Kromě toho je možné automaticky škálovat obory názvů služby Service Bus Úrovně Premium a je možné je povolit tak, aby vyhovovaly špičkám v propustnosti.

Poznámka:

Pokud není vybrána správná úroveň, existuje riziko zahlcení oboru názvů služby Service Bus, které může vést k omezování.

Omezování nemá za následek ztrátu dat. Aplikace využívající sadu Service Bus SDK můžou využít výchozí zásady opakování, aby se zajistilo, že služba Service Bus data nakonec přijme.

Výpočet propustnosti pro Premium

Data odesílaná do služby Service Bus se serializují do binárního souboru a po přijetí příjemcem se deserializují. Zatímco aplikace si zprávy myslí jako atomické jednotky práce, Service Bus měří propustnost z hlediska bajtů (nebo megabajtů).

Při výpočtu požadavku na propustnost zvažte data odesílaná do služby Service Bus (příchozí přenos dat) a data přijatá ze služby Service Bus (výchozí přenos dat).

Podle očekávání je propustnost vyšší pro menší datové části zpráv, které je možné dávkot společně.

Srovnávací testy

Tady je ukázka GitHubu, kterou můžete spustit, abyste viděli očekávanou propustnost, kterou obdržíte pro obor názvů služby Service Bus. V našich srovnávacích testech jsme zaznamenali přibližně 4 MB/s na jednotku zasílání zpráv (MU) příchozího a výchozího přenosu dat.

Ukázka srovnávacího testu nepoužívá žádné pokročilé funkce, takže propustnost, která vaše aplikace sleduje, se liší podle vašich scénářů.

Důležité informace o výpočetních prostředcích

Service Bus provozuje několik procesů na pozadí, které můžou ovlivnit využití výpočetních prostředků. Patří mezi ně mimo jiné, časovače, plány a emise metrik. Kromě toho použití určitých funkcí služby Service Bus vyžaduje využití výpočetních prostředků, které může snížit očekávanou propustnost. Některé z těchto funkcí jsou :

  1. Zasedání.
  2. Projděte si více předplatných v jednom tématu.
  3. Spouštění mnoha filtrů v jednom předplatném
  4. Naplánované zprávy
  5. Odložené zprávy.
  6. Transakce.
  7. Odstranění duplicit a zpětného časového intervalu
  8. Přeposlat na (přeposílání z jedné entity do druhé).

Pokud vaše aplikace používá některou z výše uvedených funkcí a nedostáváte očekávanou propustnost, můžete zkontrolovat metriky využití procesoru a zvážit vertikální navýšení kapacity oboru názvů Service Bus Premium. Azure Monitor můžete také využít k automatickému škálování oboru názvů služby Service Bus. Pokud využití procesoru překročí 70 %, doporučujeme zvýšit počet jednotek zpráv, aby se zajistil optimální výkon.

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

Vertikální navýšení kapacity výpočetních prostředků (jednotky zasílání zpráv) přidělené oboru názvů je jednodušším řešením, ale nemusí poskytovat lineární zvýšení propustnosti. Je to kvůli interním operacím služby Service Bus (úložiště, sítě atd.), což může omezovat propustnost.

Čistějším řešením v tomto případě je horizontální dělení entit (front a témat) napříč různými obory názvů Service Bus Premium. Můžete také zvážit horizontální dělení napříč různými obory názvů v různých oblastech Azure.

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. Protokol SBMP (Service Bus Messaging Protocol)
  3. Protokol HTTP (Hypertext Transfer Protocol)

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

Důležité

Protokol SBMP je k dispozici pouze pro rozhraní .NET Framework. AMQP je výchozí hodnota pro .NET Standard.

Dne 30. září 2026 vyřadíme podporu protokolu SBMP pro Azure Service Bus, takže tento protokol už nebudete moct používat po 30. září 2026. Migrujte na nejnovější knihovny sady SDK služby Azure Service Bus pomocí protokolu AMQP, který nabízí důležité aktualizace zabezpečení a vylepšené funkce před tímto datem.

Další informace najdete v oznámení o vyřazení podpory.

Výběr vhodné sady Service Bus .NET SDK

Balíček Azure.Messaging.ServiceBus je nejnovější sada .NET SDK služby Azure Service Bus dostupná od listopadu 2020. Existují dvě starší sady .NET SDK, které budou dál dostávat kritické opravy chyb až do 30. září 2026, ale důrazně doporučujeme používat nejnovější sadu SDK. Podrobnosti o přechodu ze starších sad SDK najdete v průvodci migrací.

Balíček NuGet Primární obory názvů Minimální platformy Protokoly
Azure.Messaging.ServiceBus (nejnovější) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Univerzální platforma Windows 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
Univerzální platforma Windows 10.0.16299		 AMQP
HTTP

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

30. září 2026 vyřadíme knihovny sady SDK služby Azure Service Bus pro WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus a com.microsoft.azure.servicebus, které nevyhovují pokynům sady Azure SDK. Také ukončíme podporu protokolu SBMP, takže tento protokol už nebudete moct používat po 30. září 2026. Před tímto datem migrujte na nejnovější knihovny sady Azure SDK, které nabízejí důležité aktualizace zabezpečení a vylepšené funkce.

I když starší knihovny je možné používat i po 30. září 2026, nebudou už od Microsoftu dostávat oficiální podporu a aktualizace. Další informace najdete v oznámení o vyřazení podpory.

Opětovné nasazení továren a klientů

Klienti služby Service Bus, kteří pracují se službou, jako jsou ServiceBusClient, ServiceBusSender, ServiceBusReceiver a ServiceBusProcessor, by měli být zaregistrovaní pro injektáž závislostí jako singletony (nebo vytvoření instance jednou a sdílené). ServiceBusClient (factory) je možné zaregistrovat pro injektáž závislostí pomocí ServiceBusClientBuilderExtensions.

Doporučujeme, abyste po odeslání nebo přijetí jednotlivých zpráv tyto klienty nezavírali nebo neodebrali. Zavření nebo likvidaci objektů specifických pro entitu (ServiceBusSender,Receiver/Processor) způsobí zrušení propojení se službou Service Bus. Při dispozici ServiceBusClient se připojení ke službě Service Bus ruší.

Tyto pokyny se nevztahují na ServiceBusSessionReceiver, protože jeho životnost je stejná jako samotná relace. Pro aplikace pracující s aplikací ServiceBusSessionReceiverse doporučuje použít jednu instanci ServiceBusClient každé relace, která zahrnuje novou ServiceBusSessionReceiver vazbu na danou relaci. Jakmile aplikace dokončí zpracování této relace, měla by likvidovat přidruženou ServiceBusSessionReceiver.

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

Poznámka:

Vytvoření připojení je náročná operace, které se můžete vyhnout opětovným použitím stejné továrny nebo klientských objektů pro více operací. Tyto klientské objekty můžete bezpečně používat pro souběžné asynchronní operace a z více vláken.

Souběžné operace

Operace, jako je odesílání, příjem, odstraňování atd., nějakou dobu trvá. Tento čas zahrnuje dobu, kterou služba Service Bus potřebuje ke zpracování operace, a latenci požadavku a odpovědi. Pokud chcete zvýšit počet operací za čas, musí se operace spouštět 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ího požadavku. 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");

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

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

Režim příjmu

Při vytváření klienta fronty nebo předplatného můžete zadat režim příjmu: Náhled uzamčení nebo přijetí a odstranění. Výchozí režim příjmu je PeekLock. Když pracujete ve výchozím režimu, klient odešle požadavek na příjem zprávy ze služby Service Bus. Jakmile klient zprávu přijme, odešle žádost o dokončení zprávy.

Když nastavíte režim příjmu na ReceiveAndDelete, oba kroky se zkombinují do jednoho požadavku. Tento postup snižuje celkový počet operací a může zlepšit celkovou propustnost zpráv. Toto zvýšení výkonu je ohroženo ztrátou zpráv.

Service Bus nepodporuje transakce pro operace příjmu a odstranění. Pro všechny scénáře, ve kterých chce klient odložit nebo pozdržet zprávu, se vyžaduje také sémantika zámku.

Předběžné načtení

Předběžné načtení umožňuje klientovi fronty nebo odběru načíst další zprávy ze služby při příjmu zpráv. Klient tyto zprávy ukládá do místní mezipaměti. Velikost mezipaměti je určena vlastnostmi ServiceBusReceiver.PrefetchCount . Každý klient, který umožňuje předběžné načtení, udržuje svou vlastní mezipaměť. Mezipaměť se nesdílí mezi klienty. Pokud klient spustí operaci příjmu a její mezipaměť je prázdná, služba odešle dávku zpráv. Pokud klient spustí operaci příjmu a mezipaměť obsahuje zprávu, zpráva se převezme z mezipaměti.

Při předběžném načtení zprávy služba uzamkne předem načtenou zprávu. Při uzamčení nemůže předem načtená zpráva přijímat jiný příjemce. Pokud příjemce nemůže zprávu dokončit před vypršením platnosti zámku, bude zpráva k dispozici ostatním příjemcům. Předem načtená kopie zprávy zůstane v mezipaměti. Příjemce, který využívá kopii uloženou v mezipaměti s vypršenou platností, obdrží výjimku, když se pokusí tuto zprávu dokončit. Ve výchozím nastavení vyprší platnost zámku zprávy po 60 sekundách. Tuto hodnotu lze prodloužit na 5 minut. Pokud chcete zabránit spotřebě zpráv s vypršenou platností, nastavte velikost mezipaměti menší než počet zpráv, které může klient spotřebovat v intervalu časového limitu uzamčení.

Pokud použijete výchozí vypršení platnosti zámku 60 sekund, je dobrá hodnota PrefetchCount 20krát maximální rychlost zpracování všech příjemců továrny. Například továrna 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í nesmí překročit 20 X 3 X 10 = 600. Ve výchozím nastavení je nastavená hodnota 0, což znamená, PrefetchCount že ze služby se nenačítají žádné další zprávy.

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

Vlastnost TTL (time-to-live) zprávy je kontrolována serverem v době, kdy server odešle zprávu klientovi. Klient při přijetí zprávy nekontroluje vlastnost TTL zprávy. Místo toho může být zpráva přijata i v případě, že se hodnota TTL zprávy předala v době, kdy klient zprávu ukládal do mezipaměti.

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

Další informace najdete v následujících PrefetchCount vlastnostech:

Hodnoty těchto vlastností můžete nastavit v ServiceBusReceiverOptions nebo ServiceBusProcessorOptions.

Předběžné načítání a receiveMessagesAsync

Přestože koncepty předběžného načítání více zpráv mají podobnou sémantiku ke zpracování zpráv v dávce (ReceiveMessagesAsync), při společném používání těchto přístupů je potřeba mít na paměti několik drobných rozdílů.

Prefetch je konfigurace (nebo režim) v ServiceBusReceiver a ReceiveMessagesAsync je operace (která má sémantiku odezvy požadavku).

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, od ReceiveMessagesAsynckterých očekáváte příjem .
  • Předběžné načtení může být až 3krát větší než počet zpracovaných zpráv za sekundu, kde n je výchozí doba trvání uzamčení.

Existuje několik problémů s přístupem greedy, tj. udržováním vysokého počtu předběžného načtení, protože to znamená, že zpráva je uzamčená konkrétnímu příjemci. Doporučujeme vyzkoušet předem načíst hodnoty, které jsou mezi dříve zmíněnými prahovými hodnotami, a určit, co vyhovuje.

Více front nebo témat

Pokud jedna fronta nebo téma nedokáže zpracovat očekávaný počet zpráv, použijte více entit zasílání zpráv. Při použití více entit vytvořte pro každou entitu vyhrazeného klienta místo použití stejného klienta pro všechny entity.

Více front nebo témat znamená, že máte více entit pro správu v době nasazení. Z hlediska škálovatelnosti ve skutečnosti není příliš mnoho rozdílu, že byste si všimli, že service Bus už rozděluje zatížení mezi více protokolů interně, takže pokud použijete šest front nebo témat nebo dvě fronty nebo témata, nebude se zásadním rozdílem.

Úroveň služby, kterou používáte, má vliv na předvídatelnost výkonu. Pokud zvolíte úroveň Standard , propustnost a latence se nejlépe hodí pro sdílenou infrastrukturu s více tenanty. Na propustnost můžou mít vliv i ostatní tenanti ve stejném clusteru. Pokud zvolíte Premium, získáte prostředky, které vám poskytnou předvídatelný výkon, a vaše více front nebo témat se zpracuje z tohoto fondu zdrojů. Další informace najdete v tématu Cenové úrovně.

Dělené obory názvů

Pokud používáte dělené obory názvů úrovně Premium, více oddílů s nižšími jednotkami zasílání zpráv (MU) poskytuje lepší výkon u jednoho oddílu s vyššími jednotkami MU.

Scénáře

Následující části popisují typické scénáře zasílání zpráv a popisují upřednostňovaná nastavení služby Service Bus. Propustnost se klasifikuje jako malá (menší než 1 zpráva za sekundu), střední (1 zpráva za sekundu nebo větší, ale menší než 100 zpráv za sekundu) a vysoká (100 zpráv za sekundu nebo vyšší). Počet klientů je klasifikován 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í více 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í více továren zpráv.
  • 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ů klientských protokolů služby Service Bus.

Několik front s vysokou propustností

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

Pokud chcete získat maximální propustnost napříč několika frontami, použijte nastavení uvedená k maximalizaci propustnosti jedné fronty. Pomocí různých továren také můžete 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í.

  • Pokud používáte jednoho klienta, nastavte počet předběžného načtení na 20krát rychlost zpracování příjemce. Pokud do fronty dorazí více zpráv najednou, klientský protokol služby Service Bus je přenáší ve stejnou dobu. Když klient obdrží další zprávu, tato zpráva je již 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 hodnotu 0. Nastavením počtu může druhý klient obdržet 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í mírou. Počet přijímačů je malý.

Service Bus umožňuje až 1 000 souběžných připojení k entitě zasílání zpráv. Tento limit se vynucuje na úrovni oboru názvů a fronty, témata nebo odběry jsou omezeny 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 předplatným. Téma přijímá od odesílatelů až 1 000 souběžných připojení. Předplatné přijímá dalších 1 000 souběžných připojení od příjemců. Pokud je vyžadováno více než 1 000 souběžných odesílatelů, měli by odesílatelé odesílat zprávy do protokolu Service Bus přes protokol HTTP.

Pokud chcete maximalizovat propustnost, postupujte takto:

  • Pokud je každý odesílatel v jiném procesu, použijte pro každý proces jenom jednu továrnu.
  • 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ů klientských protokolů služby Service Bus.

Fronta s velkým počtem příjemců

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

Service Bus umožňuje až 1 000 souběžných připojení k entitě. Pokud fronta vyžaduje více než 1 000 příjemců, nahraďte frontu tématem a více předplatnými. Každé předplatné může podporovat až 1 000 souběžných připojení. Případně můžou příjemci přistupovat k frontě prostřednictvím protokolu 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 pouze jednu továrnu.
  • Nastavte počet předběžného načtení na malou hodnotu (například PrefetchCount = 10). Tento počet brání tomu, aby příjemci byli nečinní, 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: Maximalizujte propustnost tématu s několika předplatnými. Zpráva je přijata mnoha předplatnými, což znamená, že kombinovaná 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říjemců na předplatné je malý.

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

  • Pokud chcete zvýšit celkovou míru odesílání do tématu, vytvořte odesílatele pomocí více 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 odběru, vytvořte příjemce pomocí několika továren zpráv. Pro každého příjemce použijte asynchronní operace nebo více vláken.
  • 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ů klientských protokolů služby Service Bus.

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

Cíl: Maximalizujte propustnost tématu s velkým počtem předplatných. Zpráva je přijata mnoha předplatnými, což znamená, že kombinovaná 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říjemců na předplatné je malý.

Témata s velkým počtem odběrů obvykle zpřístupňují nízkou celkovou propustnost, pokud jsou všechny zprávy směrovány do všech odběrů. 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 téma.

Pokud chcete maximalizovat propustnost, vyzkoušejte následující kroky:

  • Nastavte počet předběžného načtení na 20krát očekávanou rychlost přijetí zpráv. Tento počet snižuje počet přenosů klientských protokolů služby Service Bus.