Freigeben über

Bewährte Methoden für Leistungsoptimierungen mithilfe von Service Bus Messaging

  • Artikel

In diesem Artikel erfahren Sie, wie Sie mithilfe von Azure Service Bus die Leistung beim Austausch von im Broker gespeicherten Nachrichten optimieren. Im ersten Teil dieses Artikels werden die verschiedenen Mechanismen zur Leistungssteigerung beschrieben. Der zweite Teil bietet eine Anleitung zur Verwendung von Service Bus auf eine Weise, die die beste Leistung in einem bestimmten Szenario ermöglichen kann.

Im Rahmen dieses Artikels bezieht sich der Begriff „Client“ auf eine Entität, die auf Service Bus zugreift. Ein Client kann die Rolle eines Absenders oder eines Empfängers annehmen. Der Begriff „Absender“ wird für einen Service Bus-Warteschlangenclient oder für einen Service Bus-Themaclient verwendet, der Nachrichten an eine Service Bus-Warteschlange oder an ein Service Bus-Thema sendet. Der Begriff „Empfänger“ bezieht sich auf einen Service Bus-Warteschlangenclient oder einen auf einen Service Bus-Abonnementclient, der Nachrichten von einer Service Bus-Warteschlange oder einem Service Bus-Abonnement empfängt.

Ressourcenplanung und Überlegungen

Wie bei jeder technischen Ressource ist umsichtige Planung der Schlüssel, um sicherzustellen, dass Azure Service Bus die Leistung erbringt, die Ihre Anwendung erwartet. Die richtige Konfiguration oder Topologie für Ihre Service Bus-Namespaces hängt von einer Vielzahl von Faktoren ab, die Ihre Anwendungsarchitektur und die Art und Weise betreffen, wie die einzelnen Service Bus-Funktionen verwendet werden.

Tarif

Service Bus bietet verschiedene Tarife. Es wird empfohlen, den geeigneten Tarif für Ihre Anwendungsanforderungen auszuwählen.

  • Standard-Tarif: Geeignet für Entwickler-/Testumgebungen oder Szenarien mit geringem Durchsatz, in denen Anwendungen nicht negativ auf Drosselung reagieren.

  • Premium-Tarif: Geeignet für Produktionsumgebungen mit unterschiedlichen Durchsatzanforderungen, in denen vorhersagbare Latenz und vorhersagbarer Durchsatz erforderlich sind. Darüber hinaus können Service Bus Premium-Namespaces automatisch skaliert und aktiviert werden, um Durchsatzspitzen zu bewältigen.

Hinweis

Wenn nicht der richtige Tarif ausgewählt wird, besteht die Gefahr, dass der Service Bus-Namespace überfordert wird, was zu Drosselung führen kann.

Drosselung führt nicht zu Datenverlusten. Anwendungen, die das Service Bus SDK nutzen, können die standardmäßige Wiederholungsrichtlinie verwenden, um sicherzustellen, dass die Daten schließlich von Service Bus akzeptiert werden.

Berechnen des Durchsatzes für den Premium-Tarif

Daten, die an Service Bus gesendet werden, werden in binäre Daten serialisiert und dann deserialisiert, wenn sie vom Empfänger empfangen werden. Während Anwendungen Nachrichten als atomare Arbeitseinheiten betrachten, misst Service Bus den Durchsatz in Byte (oder Megabyte).

Berücksichtigen Sie bei der Berechnung der Durchsatzanforderung die Daten, die an Service Bus (Eingang) gesendet werden, und die Daten, die von Service Bus (Ausgang) empfangen werden.

Wie erwartet ist der Durchsatz für kleinere Nachrichtennutzdaten höher, die in Batches zusammengefasst werden können.

Vergleichstests

Hier sehen Sie ein GitHub-Beispiel, das Sie ausführen können, um den erwarteten Durchsatz zu ermitteln, den Sie für Ihren Service Bus-Namespace erhalten. In unseren Benchmarktests haben wir ungefähr 4 MB/Sekunde pro Messagingeinheit (Messaging Unit, MU) von ein- und ausgehenden Daten beobachtet.

Im Benchmarkbeispiel werden keine erweiterten Features verwendet, sodass der Durchsatz, den Ihre Anwendungen erzielen, je nach Szenario unterschiedlich ist.

Computeaspekte

Service Bus betreibt mehrere Hintergrundprozesse, die sich auf die Berechnungsauslastung auswirken können. Hierzu zählen unter anderem Timer, Zeitpläne und die Ausgabe von Metriken. Zusätzlich erfordert die Verwendung bestimmter Service Bus-Features eine Computerauslastung, die den erwarteten Durchsatz verringern kann. Einige dieser Features betreffen Folgendes:

  1. Sitzungen.
  2. Auffächern in mehrere Abonnements für ein einzelnes Thema.
  3. Ausführen zahlreicher Filter für ein einzelnes Abonnement.
  4. Geplante Nachrichten.
  5. Verzögerte Nachrichten.
  6. Transaktionen
  7. Deduplizierung und Rückschauzeitfenster.
  8. Weiterleiten (Weiterleitung von einer Entität an eine andere).

Wenn Ihre Anwendung eines der oben genannten Features verwendet und Sie nicht den erwarteten Durchsatz erzielen, können Sie die CPU-Nutzungsmetriken überprüfen und erwägen, Ihren Service Bus Premium-Namespace zentral hochzuskalieren. Sie können auch Azure Monitor verwenden, um den Service Bus-Namespace automatisch zu skalieren. Es wird empfohlen, die Anzahl der Nachrichteneinheiten (Message Units, MUs) zu erhöhen, wenn die CPU-Auslastung 70 % überschreitet, um eine optimale Leistung sicherzustellen.

Namespaceübergreifendes Sharding

Das Hochskalieren von Computeressourcen (Messagingeinheiten), die dem Namespace zugeordnet sind, ist zwar eine einfachere Lösung, führt jedoch nicht unbedingt zu einer linearen Erhöhung des Durchsatzes. Dies liegt an internen Service Bus-Einstellungen (Speicher, Netzwerk usw.), die den Durchsatz möglicherweise einschränken.

Die bessere Lösung besteht in diesem Fall in Sharding Ihrer Entitäten (Warteschlangen und Themen) über verschiedene Service Bus Premium-Namespaces hinweg. Sie können auch Sharding für verschiedene Namespaces in verschiedenen Azure-Regionen in Betracht ziehen.

Protokolle

Service Bus ermöglicht Clients das Senden und Empfangen von Nachrichten über eins von drei Protokollen:

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

AMQP ist am effizientesten, weil hierbei die Verbindung mit Service Bus aufrechterhalten wird. Außerdem implementiert es die Batchverarbeitung und Vorabrufe. Sofern nicht anders angegeben, wird für alle Inhalte in diesem Artikel AMQP oder SBMP verwendet.

Wichtig

Das SBMP-Protokoll ist nur für .NET Framework verfügbar. AMQP ist die Standardeinstellung für .NET Standard.

Am 30. September 2026 wird die Unterstützung des SBMP-Protokolls für Azure Service Bus eingestellt, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum mithilfe des AMQP-Protokolls zu den neuesten Azure Service Bus SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Auswählen des geeigneten Service Bus .NET SDK

Das Paket Azure.Messaging.ServiceBus ist das neueste Azure Service Bus .NET SDK und ab November 2020 verfügbar. Es gibt zwei ältere .NET SDKs, die bis zum 30. September 2026 weiterhin kritische Fehlerbehebungen erhalten, aber wir empfehlen dringend, stattdessen das neueste SDK zu verwenden. Ausführliche Informationen zum Wechsel von den älteren SDKs finden Sie im Migrationsleitfaden.

NuGet-Paket Primäre Namespaces Mindestplattformen Protokolle
Azure.Messaging.ServiceBus (aktuelle Version) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Universelle Windows-Plattform 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
Universelle Windows-Plattform 10.0.16299		 AMQP
HTTP

Weitere Informationen zu den Mindestplattformen für die Unterstützung von .NET Standard finden Sie unter Unterstützung der .NET-Implementierung.

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Wiederverwenden von Factorys und Clients

Die Service Bus-Clients, die mit dem Dienst interagieren (z. B. ServiceBusClient, ServiceBusSender, ServiceBusReceiver und ServiceBusProcessor), sollten für die Abhängigkeitsinjektion als Singletons registriert (oder einmal instanziiert und freigegeben) werden. ServiceBusClient (Factory) kann für die Abhängigkeitsinjektion mit den ServiceBusClientBuilderExtensions registriert werden.

Es wird empfohlen, diese Clients nach dem Senden oder Empfangen einzelner Nachrichten nicht zu schließen oder zu verwerfen. Durch das Schließen oder Verwerfen der entitätsspezifischen Objekte (ServiceBusSender/Receiver/Processor) wird die Verknüpfung zum Service Bus-Dienst getrennt. Das Verwerfen von ServiceBusClient führt dazu, dass die Verbindung mit dem Service Bus-Dienst beendet wird.

Diese Anleitung gilt nicht für serviceBusSessionReceiver, da dessen Lebensdauer der der Sitzung entspricht. Für Anwendungen, die mit ServiceBusSessionReceiver arbeiten, wird empfohlen, eine Singleton-Instanz vom ServiceBusClient zu verwenden, um jede Sitzung zu akzeptieren, wodurch ein neuer ServiceBusSessionReceiver erzeugt wird, der an die Sitzung gebunden ist. Sobald die Anwendung die Verarbeitung dieser Sitzung abgeschlossen hat, sollte sie den zugeordneten ServiceBusSessionReceiver verwerfen.

Der folgende Hinweis gilt für alle SDKs:

Hinweis

Das Herstellen einer Verbindung ist ein aufwendiger Vorgang, den Sie vermeiden können, indem Sie die Factory oder die Clientobjekte für mehrere Vorgänge verwenden. Sie können diese Clientobjekte sicher für gleichzeitige asynchrone Vorgänge und von mehreren Threads verwenden.

Parallele Vorgänge

Vorgänge wie Senden, Empfangen, Löschen usw. nehmen einige Zeit in Anspruch. Dieser Zeitraum umfasst die Zeit, die der Service-Bus-Dienst für die Bearbeitung des Vorgangs benötigt, sowie die Latenzzeit der Anforderung und der Antwort. Die Vorgänge müssen parallel ausgeführt werden, um die Anzahl von Vorgängen pro Zeitraum zu erhöhen.

Der Client plant gleichzeitige Vorgänge durch Ausführen von asynchronen Vorgängen. Die nächste Anforderung wird gestartet, bevor die vorherige Anforderung abgeschlossen ist. Im folgenden Codeausschnitt sehen Sie ein Beispiel für einen asynchronen Sendevorgang:

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

Im folgenden Code sehen Sie ein Beispiel für einen asynchronen Empfangsvorgang.

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

Empfangsmodus

Beim Erstellen eines Warteschlangen- oder Abonnementclients können Sie einen Empfangsmodus angeben: PeekLock oder ReceiveAndDelete. Der Standardempfangsmodus ist PeekLock. Beim Betrieb im Standardmodus sendet der Client eine Anforderung zum Empfangen einer Nachricht von Service Bus. Nachdem der Client die Nachricht empfangen hat, sendet er eine Anforderung zum Abschließen der Nachricht.

Wenn der Empfangsmodus auf ReceiveAndDelete festgelegt wird, werden beide Schritte in einer Anforderung kombiniert. Dieser Schritt reduziert die Anzahl der Vorgänge und kann den Gesamtnachrichtendurchsatz verbessern. Diese Leistungssteigerung kann zu Nachrichtenverlusten führen.

Service Bus unterstützt keine Transaktionen für ReceiveAndDelete-Vorgänge. Außerdem ist PeekLock-Semantik für alle Szenarien erforderlich, in denen der Client eine Nachricht zurückstellen oder in eine Warteschlange für unzustellbare Nachrichten verschieben möchte.

Vorabrufe

Vorabrufe ermöglichen es dem Warteschlangen- oder Abonnementclient, zusätzliche Nachrichten aus dem Dienst zu laden, wenn Nachrichten empfangen werden. Der Client speichert diese Nachrichten in einem lokalen Cache. Die Größe des Caches wird durch die Eigenschaft ServiceBusReceiver.PrefetchCount bestimmt. Jeder Client, der Vorabrufe ermöglicht, verwaltet seinen eigenen Cache. Ein Cache wird nicht für andere Clients freigegeben. Wenn der Client einen Empfangsvorgang startet und sein Cache leer ist, überträgt der Dienst ein Nachrichtenbatch. Wenn der Client einen Empfangsvorgang startet und der Cache eine Nachricht enthält, wird die Nachricht aus dem Cache abgerufen.

Wenn eine Nachricht vorab abgerufen wird, sperrt der Dienst die vorab abgerufene Nachricht. Durch die Sperre kann die vorabgerufene Nachricht nicht von einem anderen Empfänger empfangen werden. Wenn der Empfänger die Nachricht nicht abschließen kann, bevor die Sperre abläuft, wird die Nachricht für andere Empfänger verfügbar gemacht. Die vorab abgerufene Kopie der Nachricht verbleibt im Cache. Der Empfänger, der die abgelaufene Kopie aus dem Cache verarbeitet, empfängt eine Ausnahme, wenn er versucht, diese Nachricht abzuschließen. Standardmäßig läuft die Nachrichtensperrre nach 60 Sekunden ab. Dieser Wert kann auf 5 Minuten erhöht werden. Um die Nutzung abgelaufener Nachrichten zu verhindern, legen Sie die Cachegröße kleiner als die Anzahl der Nachrichten fest, die ein Client innerhalb des Sperrtimeoutintervalls nutzen kann.

Wenn Sie den Standardsperrenablauf von 60 Sekunden verwenden, gilt als geeigneter Wert für PrefetchCount das 20-fache der maximalen Verarbeitungsraten aller Empfänger der Factory. Beispiel: Eine Factory erstellt 10 Empfänger, und jeder Empfänger kann bis zu 10 Nachrichten pro Sekunde verarbeiten. Der Wert für den Vorabruf sollte 20 × 3 × 10 = 600 nicht überschreiten. Standardmäßig ist PrefetchCount auf „0“ festgelegt. Dies bedeutet, dass keine zusätzlichen Nachrichten aus dem Dienst abgerufen werden.

Der Vorabruf von Nachrichten vergrößert den Gesamtdurchsatz für eine Warteschlange oder ein Abonnement, da sich dadurch die Gesamtzahl von Nachrichtenvorgängen bzw. Roundtrips verringert. Das Abrufen der ersten Nachricht dauert jedoch länger (aufgrund der gestiegenen Nachrichtengröße). Das Empfangen vorab abgerufener Nachrichten aus dem Cache ist schneller, weil diese Nachrichten bereits vom Client heruntergeladen wurden.

Die Eigenschaft für die Gültigkeitsdauer (Time-to-Live, TTL) einer Nachricht wird vom Server zu dem Zeitpunkt überprüft, wenn der Server die Nachricht an den Client sendet. Der Client überprüft die TTL-Eigenschaft der Nachricht nicht, wenn die Nachricht empfangen wird. Stattdessen kann die Nachricht auch dann empfangen werden, wenn die Gültigkeitsdauer der Nachricht abgelaufen ist, während sich die Nachricht im Cache des Clients befunden hat.

Der Vorabruf wirkt sich nicht auf die Anzahl der abrechenbaren Messagingvorgänge aus und ist nur für das Service Bus-Clientprotokoll verfügbar. Das HTTP-Protokoll unterstützt keinen Vorabruf. Vorabrufe sind für synchrone und asynchrone Empfangsvorgänge verfügbar.

Weitere Informationen finden Sie unter den folgenden PrefetchCount-Eigenschaften:

Sie können Werte für diese Eigenschaften in ServiceBusReceiverOptions oder ServiceBusProcessorOptions festlegen.

Vorabruf und ReceiveMessagesAsync

Die beim gemeinsamen Vorabrufen mehrerer Nachrichten angewendeten Konzepte ähneln hinsichtlich der Semantik der Nachrichtenverarbeitung in einem Batch (ReceiveMessagesAsync). Es gibt aber einige geringfügige Unterschiede, die Sie beachten müssen, wenn Sie diese beiden Optionen gemeinsam verwenden.

Der Vorabruf ist eine Konfiguration (bzw. ein Modus) auf dem ServiceBusReceiver und ReceiveMessagesAsync ist ein Vorgang (mit Anforderung/Antwort-Semantik).

Bedenken Sie bei der gemeinsamen Verwendung dieser beiden Ansätze Folgendes:

  • Die Vorabrufanzahl muss größer oder gleich der Anzahl von Nachrichten sein, die Sie voraussichtlich mit ReceiveMessagesAsync empfangen.
  • Die Vorabrufanzahl kann bis zu n-/dreimal so groß sein wie die Anzahl von verarbeiteten Nachrichten pro Sekunde, wobei „n“ die Standardsperrdauer ist.

Ein „gieriger“ Ansatz (also das Aufrechterhalten einer sehr hohen Vorabrufanzahl) bringt einige Probleme mit sich, da er voraussetzt, dass die Nachricht auf einen bestimmten Empfänger beschränkt ist. Es wird empfohlen, Prefetch-Werte auszuprobieren, die sich zwischen den vorher genannten Schwellenwerten befinden, und zu ermitteln, welche Werte passen.

Mehrere Warteschlangen oder Themen

Wenn eine einzelne Warteschlange oder ein einzelnes Thema die erwartete Anzahl von Nachrichten nicht verarbeiten kann, verwenden Sie mehrere Messagingentitäten. Wenn Sie mehrere Entitäten verwenden, erstellen Sie einen dedizierten Client für jede Entität, statt den gleichen Client für alle Entitäten zu nutzen.

Weitere Warteschlangen oder Themen bedeuten, dass Sie mehr Entitäten zur Bereitstellungszeit verwalten müssen. Aus Sicht der Skalierbarkeit gibt es keinen großen Unterschied, den Sie bemerken würden, da Service Bus die Last bereits intern auf mehrere Protokolle verteilt, sodass es keinen wesentlichen Unterschied macht, ob Sie sechs Warteschlangen oder Themen oder zwei Warteschlangen oder Themen verwenden.

Die Dienstebene, die Sie verwenden, wirkt sich auf die Vorhersagbarkeit der Leistung aus. Wenn Sie die Standardebene auswählen, werden Durchsatz und Latenz bestmöglich in einer freigegebenen mehrinstanzenfähigen Infrastruktur verwendet. Andere Mandanten im selben Cluster können Ihren Durchsatz möglicherweise beeinflussen. Wenn Sie Premium auswählen, erhalten Sie Ressourcen, die Ihnen eine vorhersehbare Leistung bieten. Mehrere Warteschlangen oder Themen werden dann aus diesem Ressourcenpool verarbeitet. Weitere Informationen finden Sie unter Tarife.

Partitionierte Namespaces

Wenn Sie partitionierte Namespaces der Premium-Dienstebene verwenden, bieten mehrere Partitionen mit niedrigeren Messagingeinheiten (MU) eine bessere Leistung als eine einzelne Partition mit höheren MUs.

Szenarien

In den folgenden Abschnitten werden normale Messagingszenarien und die bevorzugten Service Bus-Einstellungen beschrieben. Durchsatzraten werden als klein (weniger als 1 Nachricht/Sekunde), mittel (1 Nachricht/Sekunde oder mehr, aber weniger als 100 Nachrichten/Sekunde) und hoch (100 Nachrichten/Sekunde oder mehr) klassifiziert. Die Anzahl der Clients wird als klein (5 oder weniger), mittel (mehr als 5, aber weniger als oder gleich 20) und groß (mehr als 20) klassifiziert.

Warteschlange mit hohem Durchsatz

Zielsetzung: Maximieren des Durchsatzes einer einzelnen Warteschlange. Die Anzahl der Absender und Empfänger ist klein.

  • Verwenden Sie zum Erhöhen der Gesamtsenderate an die Warteschlange mehrere Messagingfactorys, um Absender zu erstellen. Verwenden Sie für jeden Absender asynchrone Vorgänge oder mehrere Threads.
  • Verwenden Sie zum Erhöhen der Gesamtempfangsrate von der Warteschlange mehrere Messagingfactorys, um Empfänger zu erstellen.
  • Legen Sie den Wert für Vorabrufe auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Dies verringert die Anzahl der Service Bus-Clientprotokollübertragungen.

Mehrere Warteschlangen mit hohem Durchsatz

Zielsetzung: Maximieren des Gesamtdurchsatzes mehrerer Warteschlangen. Der Durchsatz einer einzelnen Warteschlange ist mittel oder hoch.

Um den maximalen Durchsatz für mehrere Warteschlangen zu erhalten, verwenden Sie die beschriebenen Einstellungen, um den Durchsatz einer einzelnen Warteschlange zu maximieren. Verwenden Sie außerdem unterschiedliche Factorys zum Erstellen von Clients, die an verschiedene Warteschlangen senden bzw. von ihnen empfangen.

Warteschlange mit niedriger Latenz

Zielsetzung: Minimieren der Latenz einer Warteschlange oder eines Themas. Die Anzahl der Absender und Empfänger ist klein. Der Durchsatz der Warteschlange ist klein oder mittel.

  • Wenn Sie einen einzelnen Client verwenden, legen Sie den Wert für den Vorabruf auf das 20-fache der Verarbeitungsrate des Empfängers fest. Wenn mehrere Nachrichten gleichzeitig in der Warteschlange ankommen, überträgt das Service Bus-Clientprotokoll sie alle zur gleichen Zeit. Wenn der Client die nächste Nachricht empfängt, befindet sich diese Nachricht bereits im lokalen Cache. Der Cache sollte klein sein.
  • Wenn mehrere Clients verwendet werden, legen Sie den Wert für den Vorabruf auf 0 fest. Auf diese Weise kann der zweite Client die zweite Nachricht empfangen, während der erste Client noch die erste Nachricht verarbeitet.

Warteschlange mit einer großen Anzahl von Absendern

Zielsetzung: Maximieren des Durchsatzes einer Warteschlange oder eines Themas mit einer großen Anzahl von Absendern. Jeder Absender sendet Nachrichten mit einer mittleren Rate. Die Anzahl der Empfänger ist klein.

Service Bus ermöglicht bis zu 1.000 gleichzeitige Verbindungen mit einer Messagingentität. Dieser Grenzwert wird auf Namespaceebene erzwungen, und Warteschlangen, Themen oder Abonnements werden durch den Grenzwert für gleichzeitige Verbindungen pro Namespace begrenzt. Bei Warteschlangen wird diese Anzahl zwischen Absendern und Empfängern aufgeteilt. Wenn alle 1.000 Verbindungen für Absender benötigt werden, ersetzen Sie die Warteschlange durch ein Thema und ein einzelnes Abonnement. Ein Thema akzeptiert bis zu 1.000 gleichzeitige Verbindungen von Absendern. Das Abonnement nimmt 1.000 zusätzliche gleichzeitige Verbindungen von Empfängern an. Wenn mehr als 1.000 gleichzeitige Absender erforderlich sind, sollten die Absender über HTTP Nachrichten an das Service Bus-Protokoll senden.

Gehen Sie folgendermaßen vor, um den Durchsatz zu maximieren:

  • Wenn sich jeder Absender in einem anderen Prozess befindet, verwenden Sie nur eine Factory pro Prozess.
  • Legen Sie den Wert für Vorabrufe auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Dies verringert die Anzahl der Service Bus-Clientprotokollübertragungen.

Warteschlange mit einer großen Anzahl von Empfängern

Zielsetzung: Maximieren der Empfangsrate einer Warteschlange oder eines Abonnements mit einer großen Anzahl von Empfängern. Jeder Empfänger empfängt Nachrichten mit einer mittleren Rate. Die Anzahl der Absender ist klein.

Service Bus ermöglicht bis zu 1.000 gleichzeitige Verbindungen mit einer Entität. Wenn für eine Warteschlange mehr als 1.000 Empfänger erforderlich sind, ersetzen Sie die Warteschlange durch ein Thema und mehrere Abonnements. Jedes Abonnement kann bis zu 1.000 gleichzeitige Verbindungen unterstützen. Alternativ können Empfänger über das HTTP-Protokoll auf die Warteschlange zugreifen.

Verwenden Sie die folgenden Richtlinien, um den Durchsatz zu maximieren:

  • Wenn sich jeder Empfänger in einem anderen Prozess befindet, verwenden Sie nur eine Factory pro Prozess.
  • Legen Sie den Wert für den Vorabruf auf einen kleinen Wert fest (z. B. "PrefetchCount" = 10). Dadurch wird verhindert, dass Empfänger über freie Kapazitäten verfügen, während andere Empfänger eine große Anzahl von Nachrichten zwischengespeichert haben.

Thema mit einigen Abonnements

Zielsetzung: Maximieren des Durchsatzes eines Themas mit einer geringen Anzahl von Abonnements. Eine Nachricht wird von zahlreichen Abonnements empfangen, was bedeutet, dass die kombinierte Empfangsrate aller Abonnements größer als die Senderate ist. Die Anzahl der Absender ist klein. Die Empfängeranzahl pro Abonnement ist gering.

Verwenden Sie die folgenden Richtlinien, um den Durchsatz zu maximieren:

  • Verwenden Sie zur Erhöhung der Gesamtsenderate für das Thema mehrere Messagingfactorys, um Absender zu erstellen. Verwenden Sie für jeden Absender asynchrone Vorgänge oder mehrere Threads.
  • Verwenden Sie zur Erhöhung der Gesamtempfangsrate aus einem Abonnement mehrere Messagingfactorys, um Empfänger zu erstellen. Verwenden Sie für jeden Empfänger asynchrone Vorgänge oder mehrere Threads.
  • Legen Sie den Wert für Vorabrufe auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Dies verringert die Anzahl der Service Bus-Clientprotokollübertragungen.

Thema mit einer großen Anzahl von Abonnements

Zielsetzung: Maximieren des Durchsatzes eines Themas mit einer großen Anzahl von Abonnements. Eine Nachricht wird von zahlreichen Abonnements empfangen, was bedeutet, dass die kombinierte Empfangsrate aller Abonnements größer als die Senderate ist. Die Anzahl der Absender ist klein. Die Empfängeranzahl pro Abonnement ist gering.

Themen mit einer großen Anzahl von Abonnements weisen normalerweise einen geringen Gesamtdurchsatz auf, wenn alle Nachrichten an alle Abonnements weitergeleitet werden. Dies liegt daran, dass jede Nachricht mehrmals empfangen wird, und alle Nachrichten in einem Thema sowie dessen Abonnements werden im gleichen Speicher gespeichert. Die Annahme besteht hier darin, dass von einer geringen Anzahl von Absendern und Empfängern pro Abonnement ausgegangen wird. Service Bus unterstützt bis zu 2000 Abonnements pro Thema.

Probieren Sie die folgenden Schritte aus, um den Durchsatz zu maximieren:

  • Legen Sie die Prefetch-Anzahl auf 20 mal die erwartete Rate fest, mit der Nachrichten empfangen werden. Dies verringert die Anzahl der Service Bus-Clientprotokollübertragungen.