Best practices voor prestatieverbeteringen met Service Bus Messaging

In dit artikel wordt beschreven hoe u Azure Service Bus prestaties kunt 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 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 afzender of ontvanger krijgen. De term 'afzender' wordt gebruikt voor een Service Bus wachtrijclient of een onderwerpclient die berichten naar een Service Bus wachtrij of een onderwerp verzendt. 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 resourcing is het belangrijk 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 prijslagen. Het wordt aanbevolen om de juiste laag voor uw toepassingsvereisten te kiezen.

• 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 ze worden ingeschakeld om pieken in de doorvoer aan te kunnen.

De doorvoer voor Premium

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

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

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

Benchmarks

Hier ziet u GitHub voorbeeld dat u kunt uitvoeren om de verwachte doorvoer te zien die u voor uw SB-naamruimte ontvangt. In onze benchmarktestshebben we ongeveer 4 MB/seconde per messaging-eenheid (MU) waargenomen voor in- en uitvoeren.

In het voorbeeld van benchmarking worden geen geavanceerde functies gebruikt, dus de doorvoer die uw toepassingen observeren, is anders op basis van uw scenario's.

Overwegingen bij het berekenen

Als u bepaalde Service Bus gebruikt, kan rekengebruik nodig zijn, wat de verwachte doorvoer kan verminderen. Enkele van deze functies zijn:

1. Sessies.
2. Fanning out to multiple subscriptions on a single topic.
3. Veel filters uitvoeren voor één abonnement.
4. Geplande berichten.
5. Uitgestelde berichten.
6. Transacties.
7. De duplicatie & tijdvenster te bekijken.
8. Doorsturen naar (doorsturen van de ene entiteit naar de andere).

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

U kunt ook gebruikmaken van Azure Monitor om de naamruimte van de Service Bus automatisch te schalen.

Sharding tussen naamruimten

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

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

Protocollen

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

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

AMQP is het meest efficiënt, omdat de verbinding met de Service Bus. Ook wordt batching en prefetching geïmplementeerd. Tenzij expliciet vermeld, wordt voor alle inhoud in dit artikel uitgenomen dat AMQP of SBMP wordt gebruikt.

De juiste Service Bus .NET SDK kiezen

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

Zie Ondersteuning voor .NET-implementatie voor meer informatie over de minimale ondersteuning voor het .NET Standard-platform.

Fabrieks- en clients hergebruiken

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

Gelijktijdige bewerkingen

Bewerkingen zoals verzenden, ontvangen, verwijderen, en dergelijke, duren enige tijd. Deze tijd omvat de tijd die de Service Bus service nodig heeft om de bewerking te verwerken, de latentie van de aanvraag en het antwoord. 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");

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

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

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

Ontvangstmodus

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

Wanneer u de ontvangstmodus ReceiveAndDelete instelt op , worden beide stappen gecombineerd in één aanvraag. Deze stappen verminderen het totale aantal bewerkingen en kunnen de algehele berichtdoorvoer verbeteren. Deze prestatieverbetering loopt het risico berichten te verliezen.

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

Batching aan clientzijde

Met batching aan de clientzijde kan een wachtrij of onderwerpclient het verzenden van een bericht voor een bepaalde periode vertragen. Als de client aanvullende berichten verstuurt tijdens deze periode, worden de berichten in één batch verstuurd. Batching aan de clientzijde zorgt er ook voor dat een wachtrij- of abonnementsclient meerdere Volledige aanvragen in één aanvraag batcht. Batchbewerkingen zijn alleen beschikbaar voor asynchrone bewerkingen Verzenden en Voltooien. Synchrone bewerkingen worden onmiddellijk verzonden naar de Service Bus service. Batching vindt niet plaats voor peek- of ontvangstbewerkingen, en batching vindt niet plaats tussen clients.

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

Task SendBatchAsync(IEnumerable<BrokeredMessage> messages);

Toegang tot batchopslag

Als u de doorvoer van een wachtrij, onderwerp of abonnement wilt verhogen, Service Bus meerdere berichten batches wanneer deze naar de interne opslag worden weg schrijven.

• Wanneer u batching in een wachtrij inschakelen, wordt het schrijven van berichten in de store en het verwijderen van berichten uit de store batched.
• Wanneer u batching voor een onderwerp inschakelen, wordt het schrijven van berichten in de store batched.
• Wanneer u batching voor een abonnement inschakelen, worden berichten uit de store batched verwijderd.
• Wanneer batchtoegang tot de opslag is ingeschakeld voor een entiteit, Service Bus een schrijfbewerking voor de winkel voor die entiteit met maximaal 20 ms vertraagd.

Aanvullende opslagbewerkingen die tijdens dit interval plaatsvinden, worden toegevoegd aan de batch. Toegang tot batchopslag is alleen van invloed op verzend- en volledige bewerkingen; ontvangstbewerkingen worden niet beïnvloed. Toegang tot batchopslag is een eigenschap van een entiteit. Batching vindt plaats in alle entiteiten die toegang tot batchopslag inschakelen.

Bij het maken van een nieuwe wachtrij, onderwerp of abonnement is batched store-toegang standaard ingeschakeld.

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

Toegang tot batchopslag heeft geen invloed op het aantal factureerbare berichtenbewerkingen. Het is een eigenschap van een wachtrij, onderwerp of abonnement. Het is onafhankelijk van de ontvangstmodus en het protocol dat wordt gebruikt tussen een client en de Service Bus service.

Prefetching

Met vooraf ontvangen 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 QueueClient.PrefetchCount eigenschappen SubscriptionClient.PrefetchCount of . Elke client die prefetching mogelijk maakt, 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. De grootte van de batch is gelijk aan de grootte van de cache of 256 kB, wat kleiner is. Als de client een ontvangstbewerking start en de cache een bericht bevat, wordt het bericht uit de cache genomen.

Wanneer een bericht vooraf is geërfd, vergrendelt de service het vooraf ontvangen bericht. Met de vergrendeling kan het vooraf ontvangen 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 opgevraagde 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. De berichtvergrendeling verloopt standaard na 60 seconden. Deze waarde kan worden verlengd tot 5 minuten. Om het verbruik van verlopen berichten te voorkomen, stelt u de cachegrootte in die kleiner is dan het aantal berichten dat een client binnen het time-outinterval van de vergrendeling kan gebruiken.

Wanneer u de standaardvergrendelingsverlooptijd van 60 seconden gebruikt, is een goede waarde voor 20 keer de maximale verwerkingssnelheid van alle ontvangers PrefetchCount van de factory. Een factory 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. Is standaard ingesteld op 0, wat betekent dat er geen extra berichten PrefetchCount worden opgehaald uit de service.

Door berichten vooraf op te halen, wordt de totale doorvoer voor een wachtrij of abonnement verhoogd, omdat het totale aantal berichtbewerkingen of retouren hierdoor afneemt. Het ophalen van het eerste bericht duurt echter langer (vanwege de toegenomen berichtgrootte). Het ontvangen van vooraf ontvangen berichten uit de cache gaat sneller omdat deze berichten al door de client zijn gedownload.

De TTL-eigenschap (Time to Live) 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 in de cache is opgeslagen door de client.

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

Prefetching en ReceiveBatch

Hoewel de concepten van het vooraf ontvangen van meerdere berichten tegelijk een vergelijkbare semantiek hebben als het verwerken van berichten in een batch ( ), zijn er enkele kleine verschillen waar u rekening mee moet houden wanneer u deze benaderingen ReceiveBatch samen gebruikt.

Prefetch is een configuratie (of modus) op de client ( en ) en is een QueueClient SubscriptionClient bewerking (met semantiek voor ReceiveBatch aanvraag/antwoord).

Houd rekening met de volgende gevallen wanneer u deze benaderingen samen gebruikt:

• De prefetch moet groter zijn dan of gelijk zijn aan het aantal berichten dat u verwacht te ontvangen van ReceiveBatch .
• Prefetch kan maximaal n/3 keer het aantal verwerkte berichten per seconde zijn, waarbij n de standaardvergrendelingsduur is.

Er zijn enkele uitdagingen bij het hebben van een innige benadering, dat wil zeggen, het aantal vooraf opgevraagde gegevens hoog houden, omdat het impliceert dat het bericht is vergrendeld voor een bepaalde ontvanger. De aanbeveling is om waarden vooraf op te halen tussen de hierboven genoemde drempelwaarden en empirisch te identificeren wat er past.

Meerdere wachtrijen

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

Ontwikkel- en testfuncties

Service Bus heeft één functie die specifiek wordt gebruikt voor ontwikkeling, die nooit mag worden gebruikt in productieconfiguraties: TopicDescription.EnableFilteringMessagesBeforePublishing .

Wanneer er nieuwe regels of filters aan het onderwerp worden toegevoegd, kunt u gebruiken om te controleren of de TopicDescription.EnableFilteringMessagesBeforePublishing nieuwe filterexpressie werkt zoals verwacht.

Scenario's

In de volgende secties worden typische berichtscenario's beschreven en worden de voorkeursinstellingen Service Bus beschreven. Doorvoersnelheden worden geclassificeerd als klein (minder dan 1 bericht/seconde), gemiddeld (1 bericht per seconde of hoger, maar minder dan 100 berichten per seconde) en hoog (100 berichten per 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 algehele verzendsnelheid naar de wachtrij wilt verhogen, gebruikt u meerdere berichtfabrieken om afzenders te maken. Gebruik voor elke afzender asynchrone bewerkingen of meerdere threads.
• Als u de algehele ontvangstsnelheid van de wachtrij wilt verhogen, gebruikt u meerdere berichtenfabrieken om ontvangers te maken.
• Gebruik asynchrone bewerkingen om te profiteren van batchbewerkingen aan de clientzijde.
• Stel het batchinterval in op 50 ms om het aantal verzendingen van Service Bus clientprotocol te verminderen. Als er meerdere afzenders worden gebruikt, verhoogt u het batching-interval tot 100 ms.
• Laat toegang tot batchopslag ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten naar de wachtrij kunnen worden geschreven.
• Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een factory. Dit aantal vermindert het aantal Service Bus clientprotocoloverdrachten.

Meerdere wachtrijen met hoge doorvoer

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

Als u een maximale doorvoer voor meerdere wachtrijen wilt verkrijgen, gebruikt u de instellingen die worden beschreven om de doorvoer van één wachtrij te maximaliseren. Gebruik ook verschillende fabrieken om clients te maken die verzenden naar of ontvangen van verschillende wachtrijen.

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.

• Schakel batching aan clientzijde uit. De client verzendt onmiddellijk een bericht.
• Schakel toegang tot batch-opslag uit. De service schrijft het bericht onmiddellijk naar de store.
• Als u één client gebruikt, stelt u het aantal vooraf op 20 keer de verwerkingssnelheid van de ontvanger in. Als er meerdere berichten tegelijk in de wachtrij binnenkomen, verzendt het Service Bus clientprotocol ze allemaal tegelijk. Wanneer de client het volgende bericht ontvangt, staat dat bericht al in de lokale cache. De cache moet klein zijn.
• Als u meerdere clients gebruikt, stelt u het aantal vooraf op 0 in. 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: De doorvoer van een wachtrij of onderwerp maximaliseren 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 berichtentiteit mogelijk. Deze limiet wordt afgedwongen op naamruimteniveau en wachtrijen, onderwerpen of abonnementen worden beperkt door de limiet voor gelijktijdige verbindingen per naamruimte. Voor wachtrijen wordt dit aantal 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 nog eens 1000 gelijktijdige verbindingen van ontvangers. Als er meer dan 1000 gelijktijdige afzenders vereist zijn, moeten de afzenders via HTTP berichten naar het Service Bus-protocol verzenden.

Volg deze stappen om de doorvoer te maximaliseren:

• Als elke afzender een ander proces heeft, gebruikt u slechts één factory per proces.
• Gebruik asynchrone bewerkingen om te profiteren van batchbewerkingen aan de clientzijde.
• Gebruik het standaardbatchinterval van 20 ms om het aantal overdrachten van Service Bus clientprotocol te verminderen.
• Laat toegang tot batchopslag ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten naar de wachtrij of het onderwerp kunnen worden geschreven.
• Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een factory. Dit aantal vermindert het aantal Service Bus clientprotocoloverdrachten.

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 een ander proces heeft, gebruikt u slechts één factory per proces.
• Ontvangers kunnen synchrone of asynchrone bewerkingen gebruiken. Gezien de gemiddelde ontvangstsnelheid van een afzonderlijke ontvanger heeft batching aan de clientzijde van een volledige aanvraag geen invloed op de ontvangstdoorvoer.
• Laat toegang tot batchopslag ingeschakeld. Deze toegang vermindert de algehele belasting van de entiteit. Het vermindert ook de algemene snelheid waarmee berichten naar 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 een groot aantal 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 door veel abonnementen ontvangen, wat betekent dat de gecombineerde ontvangstsnelheid 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 algemene verzendsnelheid naar het onderwerp wilt verhogen, gebruikt u meerdere berichtfabrieken om afzenders te maken. Gebruik voor elke afzender asynchrone bewerkingen of meerdere threads.
• Als u de algehele ontvangstsnelheid van een abonnement wilt verhogen, gebruikt u meerdere berichtenfabrieken om ontvangers te maken. Gebruik voor elke ontvanger asynchrone bewerkingen of meerdere threads.
• Gebruik asynchrone bewerkingen om te profiteren van batchbewerkingen aan de clientzijde.
• Gebruik het standaardbatchinterval van 20 ms om het aantal overdrachten van Service Bus clientprotocol te verminderen.
• Laat toegang tot batchopslag ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten naar het onderwerp kunnen worden geschreven.
• Stel het aantal prefetch in op 20 keer de maximale verwerkingssnelheid van alle ontvangers van een factory. Dit aantal vermindert het aantal Service Bus clientprotocoloverdrachten.

Onderwerp met een groot aantal abonnementen

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

Onderwerpen met een groot aantal abonnementen geven doorgaans een lage algehele doorvoer weer als alle berichten naar alle abonnementen worden doorgeleid. Dit komt doordat elk bericht vaak wordt ontvangen en alle berichten in een onderwerp en alle abonnementen in dezelfde store worden opgeslagen. Hier wordt ervan uitgegaan dat het aantal afzenders en het aantal ontvangers per abonnement klein is. Service Bus ondersteunt maximaal 2000 abonnementen per onderwerp.

Probeer de volgende stappen om de doorvoer te maximaliseren:

• Gebruik asynchrone bewerkingen om te profiteren van batchbewerkingen aan de clientzijde.
• Gebruik het standaardbatchinterval van 20 ms om het aantal overdrachten van Service Bus clientprotocol te verminderen.
• Laat toegang tot batchopslag ingeschakeld. Deze toegang verhoogt de algehele snelheid waarmee berichten naar het onderwerp kunnen worden geschreven.
• Stel het aantal prefetch in op 20 keer de verwachte ontvangstfrequentie in seconden. Dit aantal vermindert het aantal Service Bus clientprotocoloverdrachten.