Best Practices voor prestatieverbeteringen met Service Bus Messaging

  • Artikel

In dit artikel wordt beschreven hoe u Azure Service Bus gebruikt om de prestaties te optimaliseren bij het uitwisselen van brokered berichten. In het eerste deel van dit artikel worden verschillende mechanismen beschreven om de prestaties te verbeteren. Het tweede deel bevat richtlijnen voor het gebruik van Service Bus op een manier die de beste prestaties in een bepaald scenario kan bieden.

In dit artikel verwijst de term 'client' naar elke entiteit die toegang heeft tot Service Bus. Een client kan de rol van een afzender of ontvanger aannemen. De term 'afzender' wordt gebruikt voor een Service Bus-wachtrijclient of een onderwerpclient die berichten verzendt naar een Service Bus-wachtrij of een onderwerp. De term 'ontvanger' verwijst naar een Service Bus-wachtrijclient of -abonnementsclient die berichten ontvangt van een Service Bus-wachtrij of een abonnement.

Resourceplanning en overwegingen

Net als bij elke technische besteding is verstandige planning essentieel om ervoor te zorgen dat Azure Service Bus de prestaties levert die uw toepassing verwacht. De juiste configuratie of topologie voor uw Service Bus-naamruimten is afhankelijk van een groot aantal factoren die betrekking hebben op uw toepassingsarchitectuur en hoe elk van de Service Bus-functies wordt gebruikt.

Prijscategorie

Service Bus biedt verschillende prijscategorieën. Het is raadzaam om de juiste laag te kiezen voor uw toepassingsvereisten.

  • Standard-laag: geschikt voor ontwikkel-/testomgevingen of scenario's met lage doorvoer waarbij de toepassingen niet gevoelig zijn voor beperking.

  • Premium-laag : geschikt voor productieomgevingen met uiteenlopende doorvoervereisten waarbij voorspelbare latentie en doorvoer vereist zijn. Daarnaast kunnen Service Bus Premium-naamruimten automatisch worden geschaald en kunnen worden ingeschakeld om pieken in doorvoer aan te bieden.

Notitie

Als de juiste laag niet wordt gekozen, bestaat het risico dat de Service Bus-naamruimte wordt overstuurd, wat kan leiden tot beperking.

Beperking leidt niet tot gegevensverlies. Toepassingen die gebruikmaken van de Service Bus SDK kunnen gebruikmaken van het standaardbeleid voor opnieuw proberen om ervoor te zorgen dat de gegevens uiteindelijk worden geaccepteerd door Service Bus.

Doorvoer berekenen voor Premium

Gegevens die naar Service Bus worden verzonden, worden geserialiseerd naar binair en vervolgens gedeserialiseerd wanneer ze door de ontvanger worden ontvangen. Dus, terwijl toepassingen berichten beschouwen als atomische werkeenheden, meet Service Bus de doorvoer in termen van bytes (of megabytes).

Houd bij het berekenen van de doorvoervereiste rekening met de gegevens die worden verzonden naar Service Bus (inkomend verkeer) en gegevens die worden ontvangen van Service Bus (uitgaand verkeer).

Zoals verwacht is de doorvoer hoger voor kleinere nettoladingen van berichten die samen kunnen worden gebatcheerd.

Benchmarks

Hier volgt een GitHub-voorbeeld dat u kunt uitvoeren om de verwachte doorvoer te zien die u ontvangt voor uw Service Bus-naamruimte. In onze benchmarktests hebben we ongeveer 4 MB/seconde per berichteneenheid (MU) van inkomend en uitgaand verkeer waargenomen.

In het benchmarkingvoorbeeld worden geen geavanceerde functies gebruikt, dus de doorvoer die uw toepassingen observeren, verschilt op basis van uw scenario's.

Overwegingen voor berekeningen

Voor het gebruik van bepaalde Service Bus-functies is rekengebruik vereist waarmee de verwachte doorvoer kan worden verlaagd. Sommige van deze functies zijn :

  1. Sessies.
  2. Uitwaaieren naar meerdere abonnementen op één onderwerp.
  3. Het uitvoeren van veel filters voor één abonnement.
  4. Geplande berichten.
  5. Uitgestelde berichten.
  6. Transacties.
  7. Ontdubbeling en kijk terug naar het tijdvenster.
  8. Doorsturen naar (doorsturen van de ene entiteit naar een andere).

Als uw toepassing gebruikmaakt van een van de bovenstaande functies en u de verwachte doorvoer niet ontvangt, kunt u de metrische gegevens over het CPU-gebruik bekijken en overwegen om uw Service Bus Premium-naamruimte omhoog te schalen.

U kunt Azure Monitor ook gebruiken om de Service Bus-naamruimte automatisch te schalen.

Sharding tussen naamruimten

Hoewel het omhoog schalen van compute (berichteneenheden) die aan de naamruimte is toegewezen, een eenvoudigere oplossing is, biedt het mogelijk geen lineaire toename van de doorvoer. Dit komt door De interne werking van Service Bus (opslag, netwerk, enzovoort), waardoor de doorvoer mogelijk wordt beperkt.

De schonere oplossing in dit geval is het sharden van uw entiteiten (wachtrijen en onderwerpen) in verschillende Service Bus Premium-naamruimten. U kunt ook sharding in verschillende naamruimten in verschillende Azure-regio's overwegen.

Protocollen

Met Service Bus kunnen clients berichten verzenden en ontvangen via een van de drie protocollen:

  1. Advanced Message Queuing Protocol (AMQP)
  2. Service Bus Messaging Protocol (SBMP)
  3. Hypertext Transfer Protocol (HTTP)

AMQP is de meest efficiënte, omdat deze de verbinding met Service Bus onderhoudt. Het implementeert ook batchverwerking en prefetching. Tenzij expliciet vermeld, wordt voor alle inhoud in dit artikel ervan uitgegaan dat AMQP of SBMP wordt gebruikt.

Belangrijk

Het SBMP-protocol is alleen beschikbaar voor .NET Framework. AMQP is de standaardwaarde voor .NET Standard.

Op 30 september 2026 wordt de ondersteuning van het SBMP-protocol voor Azure Service Bus buiten gebruik gesteld, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure Service Bus SDK-bibliotheken met behulp van het AMQP-protocol, dat essentiële beveiligingsupdates en verbeterde mogelijkheden biedt, vóór die datum.

Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

De juiste Service Bus .NET SDK kiezen

Het Azure.Messaging.ServiceBus pakket is de nieuwste Azure Service Bus .NET SDK beschikbaar vanaf november 2020. Er zijn twee oudere .NET SDK's die tot 30 september 2026 kritieke oplossingen blijven ontvangen, maar we raden u ten zeerste aan de nieuwste SDK te gebruiken. Lees de migratiehandleiding voor meer informatie over het verplaatsen van de oudere SDK's.

NuGet-pakket Primaire naamruimten Minimale platformen Protocollen
Azure.Messaging.ServiceBus (nieuwste versie) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Universeel Windows-platform 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
Universeel Windows-platform 10.0.16299		 AMQP
HTTP

Zie .NET-implementatieondersteuning voor meer informatie over minimale ondersteuning voor .NET Standard-platformen.

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Fabrieken en clients hergebruiken

De Service Bus-clients die communiceren met de service, zoals ServiceBusClient, ServiceBusSender, ServiceBusReceiver en ServiceBusProcessor, moeten worden geregistreerd voor afhankelijkheidsinjectie als singletons (of eenmaal geïnstantieerd en gedeeld). ServiceBusClient kan worden geregistreerd voor afhankelijkheidsinjectie met de ServiceBusClientBuilderExtensions.

We raden u aan deze clients niet te sluiten of te verwijderen nadat u elk bericht hebt verzonden of ontvangen. Als u de entiteitsspecifieke objecten (ServiceBusSender/Ontvanger/Processor) sluit of disponeert, wordt de koppeling naar de Service Bus-service verwijderd. Het verwijderen van de ServiceBusClient resulteert in het afbreken van de verbinding met de Service Bus-service.

Deze richtlijnen zijn niet van toepassing op de ServiceBusSessionReceiver, omdat de levensduur hetzelfde is als de sessie zelf. Voor toepassingen die met de ServiceBusSessionReceivertoepassing werken, is het raadzaam om een singleton-exemplaar van de ServiceBusClient sessie te gebruiken om elke sessie te accepteren, die een nieuwe ServiceBusSessionReceiver gebondenheid aan die sessie omvat. Zodra de toepassing de verwerking van die sessie heeft voltooid, moet de bijbehorende ServiceBusSessionReceiversessie worden verwijderd.

De volgende opmerking is van toepassing op alle SDK's:

Notitie

Het tot stand brengen van een verbinding is een dure bewerking die u kunt voorkomen door dezelfde factory- of clientobjecten opnieuw te gebruiken voor meerdere bewerkingen. U kunt deze clientobjecten veilig gebruiken voor gelijktijdige asynchrone bewerkingen en vanuit meerdere threads.

Gelijktijdige bewerkingen

Bewerkingen zoals verzenden, ontvangen, verwijderen, enzovoort, nemen enige tijd in beslag. Deze tijd omvat de tijd die de Service Bus-service nodig heeft om de bewerking en de latentie van de aanvraag en het antwoord te verwerken. Als u het aantal bewerkingen per keer wilt verhogen, moeten bewerkingen gelijktijdig worden uitgevoerd.

De client plant gelijktijdige bewerkingen door asynchrone bewerkingen uit te voeren. De volgende aanvraag wordt gestart voordat de vorige aanvraag is voltooid. Het volgende codefragment is een voorbeeld van een asynchrone verzendbewerking:

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

De volgende code is een voorbeeld van een asynchrone ontvangstbewerking.

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

Ontvangstmodus

Wanneer u een wachtrij- of abonnementsclient maakt, kunt u een ontvangstmodus opgeven: Peek-lock of Receive and Delete. De standaard ontvangen modus is PeekLock. Wanneer de client in de standaardmodus werkt, verzendt de client een aanvraag om een bericht van Service Bus te ontvangen. Nadat de client het bericht heeft ontvangen, wordt er een aanvraag verzonden om het bericht te voltooien.

Bij het instellen van de ontvangstmodus ReceiveAndDeleteworden beide stappen gecombineerd in één aanvraag. Deze stappen verminderen het totale aantal bewerkingen en kunnen de totale doorvoer van berichten verbeteren. Deze prestatiewinst loopt het risico dat berichten verloren gaan.

Service Bus biedt geen ondersteuning voor transacties voor ontvangst- en verwijderbewerkingen. Bovendien zijn semantiek voor peek-lock vereist voor alle scenario's waarin de client een bericht wil uitstellen of een dode letter wil uitstellen.

Prefetching

Met prefetching kan de wachtrij- of abonnementsclient extra berichten van de service laden wanneer deze berichten ontvangt. De client slaat deze berichten op in een lokale cache. De grootte van de cache wordt bepaald door de ServiceBusReceiver.PrefetchCount eigenschappen. Elke client die prefetching inschakelt, onderhoudt een eigen cache. Een cache wordt niet gedeeld tussen clients. Als de client een ontvangstbewerking start en de cache leeg is, verzendt de service een batch berichten. Als de client een ontvangstbewerking start en de cache een bericht bevat, wordt het bericht uit de cache gehaald.

Wanneer een bericht vooraf is opgehaald, vergrendelt de service het vooraf gemaakte bericht. Met de vergrendeling kan het vooraf gemaakte bericht niet worden ontvangen door een andere ontvanger. Als de ontvanger het bericht niet kan voltooien voordat de vergrendeling verloopt, wordt het bericht beschikbaar voor andere ontvangers. De vooraf gemaakte kopie van het bericht blijft in de cache. De ontvanger die de verlopen kopie in de cache gebruikt, ontvangt een uitzondering wanneer het bericht wordt voltooid. Standaard verloopt de berichtvergrendeling na 60 seconden. Deze waarde kan worden uitgebreid tot 5 minuten. Als u wilt voorkomen dat verlopen berichten worden gebruikt, stelt u de cachegrootte in die kleiner is dan het aantal berichten dat een client kan gebruiken binnen het time-outinterval voor vergrendeling.

Wanneer u de standaardverlooptijd van 60 seconden gebruikt, is een goede waarde voor PrefetchCount 20 keer de maximale verwerkingssnelheid van alle ontvangers van de fabriek. Een fabriek maakt bijvoorbeeld drie ontvangers en elke ontvanger kan maximaal 10 berichten per seconde verwerken. Het aantal prefetch mag niet groter zijn dan 20 X 3 X 10 = 600. De standaardinstelling PrefetchCount is ingesteld op 0, wat betekent dat er geen extra berichten worden opgehaald uit de service.

Door berichten vooraf te maken, wordt de totale doorvoer voor een wachtrij of abonnement verhoogd, omdat hiermee het totale aantal berichtbewerkingen of retourbewerkingen wordt verminderd. Het ophalen van het eerste bericht duurt echter langer (vanwege de toegenomen berichtgrootte). Het ontvangen van vooraf gemaakte berichten uit de cache is sneller omdat deze berichten al door de client zijn gedownload.

De time-to-live-eigenschap (TTL) van een bericht wordt gecontroleerd door de server op het moment dat de server het bericht naar de client verzendt. De client controleert de TTL-eigenschap van het bericht niet wanneer het bericht wordt ontvangen. In plaats daarvan kan het bericht worden ontvangen, zelfs als de TTL van het bericht is doorgegeven terwijl het bericht is opgeslagen in de cache van de client.

Prefetching heeft geen invloed op het aantal factureerbare berichtenbewerkingen en is alleen beschikbaar voor het Service Bus-clientprotocol. Het HTTP-protocol biedt geen ondersteuning voor prefetching. Prefetching is beschikbaar voor zowel synchrone als asynchrone ontvangstbewerkingen.

Zie de volgende PrefetchCount eigenschappen voor meer informatie:

U kunt waarden instellen voor deze eigenschappen in ServiceBusReceiverOptions of ServiceBusProcessorOptions.

Prefetching en ReceiveMessagesAsync

Hoewel de concepten van het vooraf afhalen van meerdere berichten dezelfde semantiek hebben als het verwerken van berichten in een batch (ReceiveMessagesAsync), zijn er enkele kleine verschillen waarmee u rekening moet houden wanneer u deze benaderingen samen gebruikt.

Prefetch is een configuratie (of modus) op de ServiceBusReceiver en ReceiveMessagesAsync is een bewerking (die semantiek voor aanvraagrespons heeft).

Houd bij het gebruik van deze benaderingen rekening met de volgende gevallen:

  • Prefetch moet groter zijn dan of gelijk zijn aan het aantal berichten dat u verwacht te ontvangen ReceiveMessagesAsync.
  • Prefetch kan maximaal n/3 keer het aantal berichten zijn dat per seconde wordt verwerkt, waarbij n de standaardvergrendelingsduur is.

Er zijn enkele uitdagingen met het hebben van een hebzuchtige benadering, dat wil zeggen, het houden van het aantal prefetch hoog, omdat het impliceert dat het bericht is vergrendeld voor een bepaalde ontvanger. We raden u aan vooraf gemaakte waarden uit te proberen tussen de eerder genoemde drempelwaarden en te bepalen wat er past.

Meerdere wachtrijen of onderwerpen

Als één wachtrij of onderwerp het verwachte aantal berichten niet kan verwerken, gebruikt u meerdere berichtenentiteiten. Wanneer u meerdere entiteiten gebruikt, maakt u een toegewezen client voor elke entiteit in plaats van dezelfde client te gebruiken voor alle entiteiten.

Meer wachtrijen of onderwerpen betekenen dat u meer entiteiten hebt om te beheren tijdens de implementatie. Vanuit een schaalbaarheidsperspectief is er eigenlijk niet te veel verschil dat u zou merken als Service Bus de belasting al over meerdere logboeken intern verspreidt, dus als u zes wachtrijen of onderwerpen of twee wachtrijen of onderwerpen gebruikt, maakt dit geen wezenlijk verschil.

De servicelaag die u gebruikt, heeft invloed op de voorspelbaarheid van prestaties. Als u de Standard-laag kiest, zijn doorvoer en latentie het beste voor een gedeelde multitenant-infrastructuur. Andere tenants in hetzelfde cluster kunnen van invloed zijn op uw doorvoer. Als u Premium kiest, krijgt u resources die voorspelbare prestaties bieden en uw meerdere wachtrijen of onderwerpen worden verwerkt uit die resourcegroep. Zie Prijscategorieën voor meer informatie.

Gepartitioneerde naamruimten

Wanneer u gepartitioneerde Premium-laag-naamruimten gebruikt, bieden meerdere partities met lagere berichteneenheden (MU) u een betere prestaties ten opzichte van één partitie met hogere MU's.

Scenario's

In de volgende secties worden typische berichtscenario's beschreven en worden de voorkeursinstellingen van Service Bus beschreven. Doorvoersnelheden worden geclassificeerd als klein (minder dan 1 bericht/seconde), gemiddeld (1 bericht/seconde of groter, maar minder dan 100 berichten/seconde) en hoog (100 berichten/seconde of hoger). Het aantal clients wordt geclassificeerd als klein (5 of minder), gemiddeld (meer dan 5 maar kleiner dan of gelijk aan 20) en groot (meer dan 20).

Wachtrij met hoge doorvoer

Doel: maximaliseer de doorvoer van één wachtrij. Het aantal afzenders en ontvangers is klein.

  • Als u de totale verzendsnelheid in de wachtrij wilt verhogen, gebruikt u meerdere berichtfabrieken om afzenders te maken. Gebruik voor elke afzender asynchrone bewerkingen of meerdere threads.
  • Als u de totale ontvangstsnelheid van de wachtrij wilt verhogen, gebruikt u meerdere berichtfabrieken om ontvangers te maken.
  • Gebruik asynchrone bewerkingen om te profiteren van batchverwerking aan de clientzijde.
  • Laat toegang tot batched store ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten in de wachtrij kunnen worden geschreven.
  • Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een fabriek. Dit aantal vermindert het aantal verzendingen van het Service Bus-clientprotocol.

Meerdere wachtrijen met hoge doorvoer

Doel: de totale doorvoer van meerdere wachtrijen maximaliseren. De doorvoer van een afzonderlijke wachtrij is gemiddeld of hoog.

Gebruik de instellingen die worden beschreven om de doorvoer van één wachtrij te maximaliseren om de maximale doorvoer voor meerdere wachtrijen te verkrijgen. Gebruik ook verschillende factory's om clients te maken die vanuit verschillende wachtrijen verzenden of ontvangen.

Wachtrij met lage latentie

Doel: de latentie van een wachtrij of onderwerp minimaliseren. Het aantal afzenders en ontvangers is klein. De doorvoer van de wachtrij is klein of gemiddeld.

  • Batchverwerking aan de clientzijde uitschakelen. De client verzendt onmiddellijk een bericht.
  • Batched Store-toegang uitschakelen. De service schrijft het bericht onmiddellijk naar de store.
  • Als u één client gebruikt, stelt u het aantal prefetch in op 20 keer de verwerkingssnelheid van de ontvanger. Als meerdere berichten tegelijkertijd in de wachtrij aankomen, worden deze allemaal tegelijk verzonden via het Service Bus-clientprotocol. Wanneer de client het volgende bericht ontvangt, bevindt dat bericht zich al in de lokale cache. De cache moet klein zijn.
  • Als u meerdere clients gebruikt, stelt u het aantal prefetch in op 0. Door het aantal in te stellen, kan de tweede client het tweede bericht ontvangen terwijl de eerste client nog steeds het eerste bericht verwerkt.

Wachtrij met een groot aantal afzenders

Doel: maximaliseer de doorvoer van een wachtrij of onderwerp met een groot aantal afzenders. Elke afzender verzendt berichten met een gemiddeld tarief. Het aantal ontvangers is klein.

Service Bus maakt maximaal 1000 gelijktijdige verbindingen met een berichtenentiteit mogelijk. Deze limiet wordt afgedwongen op naamruimteniveau en wachtrijen, onderwerpen of abonnementen worden beperkt door de limiet van gelijktijdige verbindingen per naamruimte. Voor wachtrijen wordt dit nummer gedeeld tussen afzenders en ontvangers. Als alle 1000 verbindingen vereist zijn voor afzenders, vervangt u de wachtrij door een onderwerp en één abonnement. Een onderwerp accepteert maximaal 1000 gelijktijdige verbindingen van afzenders. Het abonnement accepteert een extra 1000 gelijktijdige verbindingen van ontvangers. Als meer dan 1000 gelijktijdige afzenders vereist zijn, moeten de afzenders berichten verzenden naar het Service Bus-protocol via HTTP.

Voer de volgende stappen uit om de doorvoer te maximaliseren:

  • Als elke afzender zich in een ander proces bevindt, gebruikt u slechts één factory per proces.
  • Gebruik asynchrone bewerkingen om te profiteren van batchverwerking aan de clientzijde.
  • Laat toegang tot batched store ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten in de wachtrij of het onderwerp kunnen worden geschreven.
  • Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een fabriek. Dit aantal vermindert het aantal verzendingen van het Service Bus-clientprotocol.

Wachtrij met een groot aantal ontvangers

Doel: Maximaliseer de ontvangstsnelheid van een wachtrij of abonnement met een groot aantal ontvangers. Elke ontvanger ontvangt berichten met een gemiddeld tarief. Het aantal afzenders is klein.

Service Bus maakt maximaal 1000 gelijktijdige verbindingen met een entiteit mogelijk. Als voor een wachtrij meer dan 1000 ontvangers zijn vereist, vervangt u de wachtrij door een onderwerp en meerdere abonnementen. Elk abonnement kan maximaal 1000 gelijktijdige verbindingen ondersteunen. Ontvangers hebben ook toegang tot de wachtrij via het HTTP-protocol.

Volg deze richtlijnen om de doorvoer te maximaliseren:

  • Als elke ontvanger zich in een ander proces bevindt, gebruikt u slechts één fabriek per proces.
  • Ontvangers kunnen synchrone of asynchrone bewerkingen gebruiken. Gezien de gemiddelde ontvangstsnelheid van een afzonderlijke ontvanger, heeft batchverwerking aan de clientzijde van een volledige aanvraag geen invloed op de doorvoer van de ontvanger.
  • Laat toegang tot batched store ingeschakeld. Deze toegang vermindert de totale belasting van de entiteit. Het verhoogt ook de algehele snelheid waarmee berichten in de wachtrij of het onderwerp kunnen worden geschreven.
  • Stel het aantal prefetch in op een kleine waarde (bijvoorbeeld PrefetchCount = 10). Dit aantal voorkomt dat ontvangers inactief zijn terwijl andere ontvangers grote aantallen berichten in de cache hebben opgeslagen.

Onderwerp met een paar abonnementen

Doel: Maximaliseer de doorvoer van een onderwerp met een paar abonnementen. Een bericht wordt ontvangen door veel abonnementen, wat betekent dat het gecombineerde ontvangsttarief voor alle abonnementen groter is dan de verzendsnelheid. Het aantal afzenders is klein. Het aantal ontvangers per abonnement is klein.

Volg deze richtlijnen om de doorvoer te maximaliseren:

  • Als u de algehele verzendsnelheid in het onderwerp wilt verhogen, gebruikt u meerdere berichtfabrieken om afzenders te maken. Gebruik voor elke afzender asynchrone bewerkingen of meerdere threads.
  • Als u het totale ontvangstpercentage van een abonnement wilt verhogen, gebruikt u meerdere berichtfabrieken om ontvangers te maken. Gebruik voor elke ontvanger asynchrone bewerkingen of meerdere threads.
  • Gebruik asynchrone bewerkingen om te profiteren van batchverwerking aan de clientzijde.
  • Laat toegang tot batched store ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten in het onderwerp kunnen worden geschreven.
  • Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een fabriek. Dit aantal vermindert het aantal verzendingen van het Service Bus-clientprotocol.

Onderwerp met een groot aantal abonnementen

Doel: maximaliseer de doorvoer van een onderwerp met een groot aantal abonnementen. Een bericht wordt ontvangen door veel abonnementen, wat betekent dat het gecombineerde ontvangsttarief voor alle abonnementen groter is dan de verzendsnelheid. Het aantal afzenders is klein. Het aantal ontvangers per abonnement is klein.

Onderwerpen met een groot aantal abonnementen stellen doorgaans een lage totale doorvoer beschikbaar als alle berichten naar alle abonnementen worden doorgestuurd. Dit komt doordat elk bericht meerdere keren wordt ontvangen en alle berichten in een onderwerp en alle bijbehorende abonnementen worden opgeslagen in dezelfde store. De veronderstelling hier is dat het aantal afzenders en het aantal ontvangers per abonnement klein is. Service Bus ondersteunt maximaal 2000 abonnementen per onderwerp.

Voer de volgende stappen uit om de doorvoer te maximaliseren:

  • Gebruik asynchrone bewerkingen om te profiteren van batchverwerking aan de clientzijde.
  • Laat toegang tot batched store ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten in het onderwerp kunnen worden geschreven.
  • Stel het aantal prefetch in op 20 keer de verwachte snelheid waarmee berichten worden ontvangen. Dit aantal vermindert het aantal verzendingen van het Service Bus-clientprotocol.