Metodtips för prestandaförbättringar med hjälp av Service Bus meddelanden

Den här artikeln beskriver hur du använder Azure Service Bus för att optimera prestanda vid utbyte av a brokered-meddelanden. I den första delen av den här artikeln beskrivs olika mekanismer för att öka prestandan. Den andra delen innehåller vägledning om hur Service Bus på ett sätt som kan erbjuda bästa prestanda i ett visst scenario.

I den här artikeln refererar termen "klient" till alla entiteter som har åtkomst Service Bus. En klient kan ta rollen som avsändare eller mottagare. Termen "avsändare" används för en Service Bus-köklient eller en ämnesklient som skickar meddelanden till en Service Bus-kö eller ett ämne. Termen "mottagare" syftar på en klient Service Bus kö eller prenumerationsklient som tar emot meddelanden från en Service Bus-kö eller en prenumeration.

Resursplanering och överväganden

Precis som med alla tekniska resurser är klok planering nyckeln för att säkerställa att Azure Service Bus ger den prestanda som ditt program förväntar sig. Rätt konfiguration eller topologi för dina Service Bus-namnområden beror på en mängd faktorer som rör din programarkitektur och hur var och en Service Bus-funktionerna används.

Prisnivå

Service Bus erbjuder olika prisnivåer. Vi rekommenderar att du väljer lämplig nivå för dina programkrav.

• Standardnivå – Passar för utvecklar-/testmiljöer eller scenarier med lågt dataflöde där programmen inte är känsliga för begränsning.

• Premium nivå – Passar för produktionsmiljöer med varierande dataflödeskrav där förutsägbar svarstid och dataflöde krävs. Dessutom kan Service Bus premium-namnrymder skalas automatiskt och aktiveras för att hantera toppar i dataflödet.

Beräkna dataflöde för Premium

Data som skickas till Service Bus serialiseras till binär och deserialiseras sedan när de tas emot av mottagaren. Även om program ser meddelanden som atomiska arbetsenheter mäter Service Bus dataflöde i form av byte (eller megabyte).

När du beräknar dataflödeskravet bör du tänka på de data som skickas till Service Bus (ingress) och data som tas emot från Service Bus (utgående).

Som förväntat är dataflödet högre för mindre meddelandenyttolaster som kan batchas tillsammans.

Benchmark-värden

Här är ett GitHub exempel som du kan köra för att se det förväntade dataflödet som du får för SB-namnområdet. I våra benchmark-testerobserverade vi cirka 4 MB per sekund per meddelandeenhet (MU) för ingress och egress.

Benchmarking-exemplet använder inte några avancerade funktioner, så det dataflöde som dina program observerar skiljer sig beroende på dina scenarier.

Beräkningsöverväganden

Användning av Service Bus funktioner kan kräva beräkningsanvändning som kan minska det förväntade dataflödet. Några av dessa funktioner är :

1. Sessioner.
2. Stöd för flera prenumerationer i ett enda ämne.
3. Köra många filter på en enda prenumeration.
4. Schemalagda meddelanden.
5. Uppskjutna meddelanden.
6. Transaktioner.
7. Deduplicering & ett bakåttidsfönster.
8. Vidarebefordra till (vidarebefordra från en entitet till en annan).

Om ditt program använder någon av ovanstående funktioner och du inte får det förväntade dataflödet kan du granska måtten för CPU-användning och överväga att skala upp Service Bus Premium namnområdet.

Du kan också använda Azure Monitor för att automatiskt skala Service Bus namnområdet.

Horisontell partitionering mellan namnområden

Att skala upp Beräkning (meddelandeenheter) som allokerats till namnområdet är en enklare lösning, men det kanske inte ger någon linjär ökning av dataflödet. Detta beror på Service Bus internt (lagring, nätverk osv.), vilket kan begränsa dataflödet.

Den renare lösningen i det här fallet är att fragmenta dina entiteter (köer och ämnen) mellan Service Bus Premium namnområden. Du kan också överväga horisontell partitionering över olika namnrymder i olika Azure-regioner.

Protokoll

Service Bus gör att klienter kan skicka och ta emot meddelanden via något av tre protokoll:

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

AMQP är det mest effektiva, eftersom det upprätthåller anslutningen till Service Bus. Den implementerar också batchbearbetning och förbearbetningav . Om inget annat anges förutsätter allt innehåll i den här artikeln att AMQP eller SBMP används.

Välja lämplig Service Bus .NET SDK

Paketet Azure.Messaging.ServiceBus är den senaste versionen av Azure Service Bus .NET SDK som är tillgänglig från november 2020. Det finns två äldre .NET SDK:er som fortsätter att få kritiska felkorrigeringar, men vi rekommenderar starkt att du använder den senaste SDK:n i stället. Läs migreringsguiden för mer information om hur du flyttar från äldre SDK:er.

Mer information om minsta stöd för .NET Standard-plattformen finns i .NET-implementeringsstöd.

Återanvända fabriker och klienter

Följande kommentar gäller för alla -SDK:er:

Samtidiga åtgärder

Åtgärder som att skicka, ta emot, ta bort och så vidare tar lite tid. Den här tiden omfattar den tid Service Bus tjänsten tar att bearbeta åtgärden samt svarstiden för begäran och svaret. Om du vill öka antalet åtgärder per tid måste åtgärderna köras samtidigt.

Klienten schemalägger samtidiga åtgärder genom att utföra asynkrona åtgärder. Nästa begäran startas innan föregående begäran har slutförts. Följande kodfragment är ett exempel på en asynkron send-åtgärd:

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

Följande kod är ett exempel på en asynkron mottagningsåtgärd.

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

Mottagningsläge

När du skapar en kö- eller prenumerationsklient kan du ange ett mottagningsläge: Peek-lock eller Receive (Ta emot) och Delete (Ta bort). Standardläget för mottagning är PeekLock . När klienten arbetar i standardläget skickar den en begäran om att ta emot ett meddelande från Service Bus. När klienten har tagit emot meddelandet skickar den en begäran om att slutföra meddelandet.

När du ställer in mottagningsläget ReceiveAndDelete på kombineras båda stegen i en enda begäran. De här stegen minskar det totala antalet åtgärder och kan förbättra det totala meddelandeflödet. Den här prestandaökningen riskerar att förlora meddelanden.

Service Bus stöder inte transaktioner för mottagnings- och borttagningsåtgärder. Dessutom krävs peek-lock-semantik för alla scenarier där klienten vill skjuta upp eller skriva ett meddelande utan bokstav.

Batchbearbetning på klientsidan

Med batchbearbetning på klientsidan kan en kö- eller ämnesklient fördröja sändningen av ett meddelande under en viss tidsperiod. Om klienten skickar ytterligare meddelanden under den här tiden överförs dessa meddelanden i en enskild batch. Batchbearbetning på klientsidan gör också att en kö- eller prenumerationsklient batchar flera fullständiga begäranden till en enda begäran. Batchbearbetning är endast tillgängligt för asynkrona åtgärder för att skicka och slutföra. Synkrona åtgärder skickas omedelbart till Service Bus tjänsten. Batchbearbetning sker inte för att granska eller ta emot åtgärder, och batchbearbetning sker inte heller mellan klienter.

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

Task SendBatchAsync(IEnumerable<BrokeredMessage> messages);

Åtkomst till batchbearbetningslager

Om du vill öka dataflödet för en kö, ett ämne eller en prenumeration Service Bus flera meddelanden när den skriver till sitt interna arkiv.

• När du aktiverar batchbearbetning i en kö batchas skrivning av meddelanden till arkivet och borttagning av meddelanden från arkivet.
• När du aktiverar batchbearbetning för ett ämne batchas skrivning av meddelanden till arkivet.
• När du aktiverar batchbearbetning för en prenumeration batchas borttagning av meddelanden från arkivet.
• När batchbearbetningsåtkomst har aktiverats för en entitet Service Bus en butiksskrivningsåtgärd för entiteten med upp till 20 ms.

Ytterligare lagringsåtgärder som inträffar under det här intervallet läggs till i batchen. Åtkomst till Batched Store påverkar endast åtgärderna Skicka och Slutför. mottagningsåtgärder påverkas inte. Åtkomst till Batched Store är en egenskap för en entitet. Batchbearbetning sker över alla entiteter som möjliggör åtkomst till batchlager.

När du skapar en ny kö, ett ämne eller en prenumeration är batchindelade lagringsåtkomst aktiverat som standard.

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

Åtkomst till Batched Store påverkar inte antalet fakturerbara meddelandeåtgärder. Det är en egenskap för en kö, ett ämne eller en prenumeration. Den är oberoende av mottagningsläget och protokollet som används mellan en klient och Service Bus tjänsten.

Prefetching

Med förinläsning kan kö- eller prenumerationsklienten läsa in ytterligare meddelanden från tjänsten när den tar emot meddelanden. Klienten lagrar dessa meddelanden i en lokal cache. Storleken på cachen bestäms av QueueClient.PrefetchCount egenskaperna SubscriptionClient.PrefetchCount eller . Varje klient som aktiverar förlagring har sin egen cache. En cache delas inte mellan klienter. Om klienten startar en mottagningsåtgärd och dess cache är tom skickar tjänsten en batch med meddelanden. Batchstorleken är lika med storleken på cachen eller 256 kB, beroende på vilket som är mindre. Om klienten startar en mottagningsåtgärd och cachen innehåller ett meddelande tas meddelandet från cachen.

När ett meddelande har förinbokats låser tjänsten det förinplanerade meddelandet. Med låset kan det förinstallerade meddelandet inte tas emot av en annan mottagare. Om mottagaren inte kan slutföra meddelandet innan låset upphör att gälla blir meddelandet tillgängligt för andra mottagare. Den förinplanerade kopian av meddelandet finns kvar i cacheminnet. Mottagaren som använder den cachelagrade kopian som har upphört att gälla får ett undantag när den försöker slutföra meddelandet. Som standard upphör meddelandelåset att gälla efter 60 sekunder. Det här värdet kan utökas till 5 minuter. Om du vill förhindra förbrukningen av utgångna meddelanden anger du en cachestorlek som är mindre än antalet meddelanden som en klient kan använda inom tidsgränsintervallet för låsning.

När du använder standardlåsets giltighetstid på 60 sekunder är ett bra värde för 20 gånger den maximala PrefetchCount bearbetningsfrekvensen för alla mottagare av fabriken. En fabrik skapar till exempel tre mottagare och varje mottagare kan bearbeta upp till 10 meddelanden per sekund. Antalet förinställningar får inte överstiga 20 x 3 x 10 = 600. Som standard PrefetchCount är inställt på 0, vilket innebär att inga ytterligare meddelanden hämtas från tjänsten.

Om du förinstallerar meddelanden ökar det totala dataflödet för en kö eller prenumeration eftersom det minskar det totala antalet meddelandeåtgärder eller tur och retur-resor. Det tar dock längre tid att hämta det första meddelandet (på grund av den ökade meddelandestorleken). Det går snabbare att ta emot förinplanerade meddelanden från cacheminnet eftersom dessa meddelanden redan har laddats ned av klienten.

Egenskapen time-to-live (TTL) för ett meddelande kontrolleras av servern när servern skickar meddelandet till klienten. Klienten kontrollerar inte meddelandets TTL-egenskap när meddelandet tas emot. I stället kan meddelandet tas emot även om meddelandets TTL-värde har passerat medan meddelandet cachelagrades av klienten.

Förfetching påverkar inte antalet fakturerbara meddelandeåtgärder och är endast tillgängligt för Service Bus klientprotokollet. HTTP-protokollet stöder inte förlagring. Förlagring är tillgängligt för både synkrona och asynkrona mottagningsåtgärder.

Förfetching och ReceiveBatch

Även om begreppen för att prefeta flera meddelanden tillsammans har liknande semantik som vid bearbetning av meddelanden i en batch ( ), finns det några mindre skillnader som du måste ha i åtanke när du använder ReceiveBatch dessa metoder tillsammans.

Prefetch är en konfiguration (eller läge) på klienten ( och ) och är en åtgärd (som har semantik QueueClient SubscriptionClient för ReceiveBatch begäran-svar).

När du använder dessa metoder tillsammans bör du tänka på följande fall:

• Prefetch ska vara större än eller lika med antalet meddelanden som du förväntar dig att ta emot från ReceiveBatch .
• Prefetch kan vara upp till n/3 gånger antalet meddelanden som bearbetas per sekund, där n är standardlåsvaraktigheten.

Det finns vissa utmaningar med att ha en girig metod, det vill säga att hålla prefetchantalet högt, eftersom det innebär att meddelandet är låst till en viss mottagare. Rekommendationen är att testa prefetch-värden mellan de tröskelvärden som nämns ovan och empiriskt identifiera vad som passar.

Flera köer

Om en enskild kö eller ett ämne inte kan hantera det förväntade kan du använda flera meddelandeentiteter. När du använder flera entiteter skapar du en dedikerad klient för varje entitet, i stället för att använda samma klient för alla entiteter.

Funktioner för utveckling och testning

Service Bus har en funktion som används specifikt för utveckling, som aldrig ska användas i produktionskonfigurationer: TopicDescription.EnableFilteringMessagesBeforePublishing .

När nya regler eller filter läggs till i ämnet kan du använda för TopicDescription.EnableFilteringMessagesBeforePublishing att kontrollera att det nya filteruttrycket fungerar som förväntat.

Scenarier

I följande avsnitt beskrivs vanliga meddelandescenarier och de rekommenderade Service Bus inställningar. Dataflödesfrekvensen klassificeras som liten (mindre än 1 meddelande/sekund), måttlig (1 meddelande per sekund eller större men mindre än 100 meddelanden per sekund) och hög (100 meddelanden per sekund eller mer). Antalet klienter klassificeras som små (5 eller färre), måttliga (fler än 5 men mindre än eller lika med 20) och stora (fler än 20).

Kö för högt dataflöde

Mål: Maximera dataflödet för en enskild kö. Antalet avsändare och mottagare är litet.

• Om du vill öka den totala skicka-frekvensen till kön använder du flera meddelandefabriker för att skapa avsändare. Använd asynkrona åtgärder eller flera trådar för varje avsändare.
• Om du vill öka den totala mottagningsfrekvensen från kön använder du flera meddelandefabriker för att skapa mottagare.
• Använd asynkrona åtgärder för att dra nytta av batchbearbetning på klientsidan.
• Ange batchbearbetningsintervallet till 50 ms för att minska antalet Service Bus klientprotokollöverföringar. Om flera avsändare används ökar du batchbearbetningsintervallet till 100 ms.
• Låt batchbearbetningsåtkomst vara aktiverat. Den här åtkomsten ökar den övergripande hastigheten som meddelanden kan skrivas till kön med.
• Ange förinjning till 20 gånger den maximala bearbetningstakten för alla mottagare av en fabrik. Det här antalet minskar antalet överföringar Service Bus klientprotokoll.

Flera köer med högt dataflöde

Mål: Maximera det totala dataflödet för flera köer. Dataflödet för en enskild kö är måttligt eller högt.

Om du vill få maximalt dataflöde över flera köer använder du de inställningar som beskrivs för att maximera dataflödet för en enskild kö. Använd också olika fabriker för att skapa klienter som skickar eller tar emot från olika köer.

Kö för låg latens

Mål: Minimera svarstiden för en kö eller ett ämne. Antalet avsändare och mottagare är litet. Köns dataflöde är litet eller måttligt.

• Inaktivera batchbearbetning på klientsidan. Klienten skickar omedelbart ett meddelande.
• Inaktivera åtkomst till batchlager. Tjänsten skriver omedelbart meddelandet till butiken.
• Om du använder en enda klient anger du förinräkning till 20 gånger bearbetningshastigheten för mottagaren. Om flera meddelanden tas emot i kön samtidigt Service Bus klientprotokollet dem på samma gång. När klienten får nästa meddelande finns meddelandet redan i det lokala cacheminnet. Cachen ska vara liten.
• Om du använder flera klienter anger du antalet prefetch till 0. Genom att ange antalet kan den andra klienten ta emot det andra meddelandet medan den första klienten fortfarande bearbetar det första meddelandet.

Köa med ett stort antal avsändare

Mål: Maximera dataflödet för en kö eller ett ämne med ett stort antal avsändare. Varje avsändare skickar meddelanden med en måttlig hastighet. Antalet mottagare är litet.

Service Bus upp till 1 000 samtidiga anslutningar till en meddelandeentitet. Den här gränsen tillämpas på namnområdesnivå och köer, ämnen eller prenumerationer begränsas av gränsen för samtidiga anslutningar per namnområde. För köer delas det här numret mellan avsändare och mottagare. Om alla 1 000 anslutningar krävs för avsändare ersätter du kön med ett ämne och en enda prenumeration. Ett ämne accepterar upp till 1 000 samtidiga anslutningar från avsändare. Prenumerationen accepterar ytterligare 1 000 samtidiga anslutningar från mottagarna. Om fler än 1 000 samtidiga avsändare krävs ska avsändarna skicka meddelanden till Service Bus protokollet via HTTP.

Följ dessa steg om du vill maximera dataflödet:

• Om varje avsändare är i en annan process använder du bara en enda fabrik per process.
• Använd asynkrona åtgärder för att dra nytta av batchbearbetning på klientsidan.
• Använd standardintervallet för batchbearbetning på 20 ms för att minska Service Bus av klientprotokollöverföringar.
• Låt batchbearbetningsåtkomst vara aktiverat. Den här åtkomsten ökar den övergripande frekvensen för meddelanden som kan skrivas till kön eller ämnet.
• Ange förinjning till 20 gånger den maximala bearbetningstakten för alla mottagare av en fabrik. Det här antalet minskar antalet överföringar Service Bus klientprotokoll.

Köa med ett stort antal mottagare

Mål: Maximera mottagningsfrekvensen för en kö eller prenumeration med ett stort antal mottagare. Varje mottagare tar emot meddelanden med en måttlig hastighet. Antalet avsändare är litet.

Service Bus tillåter upp till 1 000 samtidiga anslutningar till en entitet. Om en kö kräver mer än 1 000 mottagare ersätter du kön med ett ämne och flera prenumerationer. Varje prenumeration har stöd för upp till 1 000 samtidiga anslutningar. Alternativt kan mottagare komma åt kön via HTTP-protokollet.

Om du vill maximera dataflödet följer du dessa riktlinjer:

• Om varje mottagare finns i en annan process använder du bara en enda fabrik per process.
• Mottagarna kan använda synkrona eller asynkrona åtgärder. Med tanke på den måttliga mottagningsfrekvensen för en enskild mottagare påverkar batchbearbetning på klientsidan av en fullständig begäran inte mottagargenomflödet.
• Låt batchbearbetningsåtkomst vara aktiverat. Den här åtkomsten minskar den totala belastningen för entiteten. Det minskar också den övergripande hastigheten med vilken meddelanden kan skrivas till kön eller ämnet.
• Ange prefetch-antalet till ett litet värde (till exempel PrefetchCount = 10). Det här antalet förhindrar att mottagare är inaktiva medan andra mottagare har ett stort antal meddelanden cachelagrade.

Ämne med några prenumerationer

Mål: Maximera dataflödet för ett ämne med några prenumerationer. Ett meddelande tas emot av många prenumerationer, vilket innebär att det kombinerade mottagningspriset för alla prenumerationer är större än skicka-priset. Antalet avsändare är litet. Antalet mottagare per prenumeration är litet.

Om du vill maximera dataflödet följer du dessa riktlinjer:

• Använd flera meddelandefabriker för att skapa avsändare för att öka den totala skicka-frekvensen till ämnet. Använd asynkrona åtgärder eller flera trådar för varje avsändare.
• Om du vill öka den totala mottagningsfrekvensen från en prenumeration använder du flera meddelandefabriker för att skapa mottagare. Använd asynkrona åtgärder eller flera trådar för varje mottagare.
• Använd asynkrona åtgärder för att dra nytta av batchbearbetning på klientsidan.
• Använd standardintervallet för batchbearbetning på 20 ms för att minska Service Bus av klientprotokollöverföringar.
• Låt batchbearbetningsåtkomst vara aktiverat. Den här åtkomsten ökar den övergripande hastigheten som meddelanden kan skrivas till ämnet med.
• Ange förinjning till 20 gånger den maximala bearbetningstakten för alla mottagare av en fabrik. Det här antalet minskar antalet överföringar Service Bus klientprotokoll.

Ämne med ett stort antal prenumerationer

Mål: Maximera dataflödet för ett ämne med ett stort antal prenumerationer. Ett meddelande tas emot av många prenumerationer, vilket innebär att det kombinerade mottagningspriset för alla prenumerationer är mycket större än skicka-priset. Antalet avsändare är litet. Antalet mottagare per prenumeration är litet.

Ämnen med ett stort antal prenumerationer exponerar vanligtvis ett lågt övergripande dataflöde om alla meddelanden dirigeras till alla prenumerationer. Det beror på att varje meddelande tas emot många gånger och alla meddelanden i ett ämne och alla dess prenumerationer lagras i samma butik. Antagandet här är att antalet avsändare och antalet mottagare per prenumeration är litet. Service Bus har stöd för upp till 2 000 prenumerationer per ämne.

Prova följande steg för att maximera dataflödet:

• Använd asynkrona åtgärder för att dra nytta av batchbearbetning på klientsidan.
• Använd standardintervallet för batchbearbetning på 20 ms för att minska Service Bus av klientprotokollöverföringar.
• Låt batchbearbetningsåtkomst vara aktiverat. Den här åtkomsten ökar den övergripande hastigheten som meddelanden kan skrivas till ämnet med.
• Ange förinställt antal till 20 gånger den förväntade mottagningsfrekvensen i sekunder. Det här antalet minskar antalet överföringar Service Bus klientprotokoll.