(0) exportieren Drucken
Alle erweitern

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

Letzte Aktualisierung: Juni 2014

Dieses Thema beschreibt die Verwendung von Microsoft Azure Service Bus zum Optimieren der Leistung, wenn Brokernachrichten ausgetauscht werden. Im ersten Teil dieses Themas werden die verschiedenen Mechanismen beschrieben, die zur Leistungsoptimierung angeboten werden. Der zweite Teil stellt Informationen dazu zur Verfügung, wie Servicebus so verwendet werden kann, dass die bestmögliche Leistung in einem bestimmten Szenario erzielt wird.

In diesem Thema bezieht sich der Begriff "Client" auf jede Entität, die auf Servicebus zugreifen kann. Ein Client kann die Rolle eines Absenders oder eines Empfängers annehmen. Der Begriff "Absender" wird für eine Servicebus-Warteschlange oder einen -Themaclient verwendet, der Nachrichten an eine Servicebus-Warteschlange oder ein -Thema sendet. Der Begriff "Empfänger " wird für eine Servicebus-Warteschlange oder einen -Abonnementclient verwendet, der Nachrichten von einer Servicebus-Warteschlange oder einem -Abonnement empfängt.

In diesem Abschnitt werden verschiedene Konzepte vorgestellt, die von Servicebus umgesetzt werden, um die Leistung zu optimieren.

Servicebus ermöglicht Clients das Senden und Empfangen von Nachrichten mithilfe von zwei Protokollen: dem Servicebus Client-Protokoll und HTTP. Das Servicebus-Clientprotokoll ist effizienter, weil es die Verbindung mit dem Servicebusdienst so lange aufrecht erhält, wie die Nachrichtenfactory vorhanden ist. Außerdem implementiert es Batchverarbeitung und Vorabrufe. Das Servicebus Client-Protokoll ist für .NET-Anwendungen verfügbar, die die verwaltete .NET-API verwenden.

Wenn nicht ausdrücklich etwas anderes gesagt wird, wird in diesem Thema das Servicebus Client-Protokoll verwendet.

Servicebus Client-Objekte (z. B. QueueClient oder MessageSender) werden mithilfe eines MessagingFactory-Objekts erstellt, das auch die interne Verwaltung von Verbindungen zur Verfügung stellt. Sie sollten Messagingfactorys oder Warteschlangen-, Thema- und Abonnementclients nach dem Senden einer Nachricht nicht schließen und dann beim Senden der nächsten Nachricht erneut erstellen. Durch das Schließen einer Messagingfactory wird die Verbindung mit dem Servicebusdienst gelöscht, und eine neue Verbindung wird beim erneuten Erstellen der Factory erstellt. Das Herstellen einer Verbindung ist ein teurer Vorgang, der durch Wiederverwenden der gleichen Factory und der Clientobjekte für mehrere Vorgänge vermieden werden kann.

Das Ausführen eines Vorgangs (Senden, Empfangen, Löschen usw.) nimmt einige Zeit in Anspruch. Diese Zeitspanne beinhaltet die Verarbeitung des Vorgangs durch den Servicebusdienst sowie die Wartezeit für die Anforderung und die Antwort. Damit die Anzahl der Vorgänge pro Zeiteinheit gesteigert wird, müssen Vorgänge gleichzeitig ausgeführt werden. Dies kann auf verschiedene Weise geschehen:

  • Asynchrone Vorgänge: Der Client stellt Vorgänge in eine Pipeline, indem asynchrone Vorgänge ausgeführt werden. Die nächste Anforderung wird gestartet, bevor die vorherige Anforderung abgeschlossen wurde. Im Folgenden finden Sie ein Beispiel für einen asynchronenSendevorgang:

    BrokeredMessage m1 = new BrokeredMessage(body);
    BrokeredMessage m2 = new BrokeredMessage(body);
    queueClient.BeginSend(m1, processEndSend, queueClient); // Send message 1.
    queueClient.BeginSend(m2, processEndSend, queueClient); // Send message 2.
    
    void processEndSend(IAsyncResult result)
    {
        QueueClient qc = result.AsyncState as QueueClient;
        qc.EndSend(result);
        Console.WriteLine("Message sent");
    }
    
    Das folgende Beispiel zeigt einen asynchronenEmpfangsvorgang:

    queueClient.BeginReceive(processEndReceive, queueClient); // Receive message 1.
    queueClient.BeginReceive(processEndReceive, queueClient); // Receive message 2.
    
    void processEndReceive(IAsyncResult result) 
    {
        QueueClient qc = result.AsyncState as QueueClient;
        BrokeredMessage m = qc.EndReceive(result);
        m.BeginComplete(processEndComplete, m);
        Console.WriteLine("Received message " + m.Label);
    }
    
    void processEndComplete(IAsyncResult result)
    {
        BrokeredMessage m = result.AsyncState as BrokeredMessage;
        m.EndComplete(result);
        Console.WriteLine("Completed message " + m.Label);
    }
    
  • Mehrere Factorys: Alle Clients (Absender und Empfänger), die von der gleichen Factory erstellt werden, verwenden eine TCP-Verbindung gemeinsam. Der maximale Nachrichtendurchsatz ist durch die Anzahl der Vorgänge eingeschränkt, die diese TCP-Verbindung durchlaufen können. Der Durchsatz, der mit einer einzelnen Factory erzielt werden kann, unterscheidet sich durch die TCP-Roundtripzeit und die Nachrichtengröße erheblich. Wenn Sie bessere Durchsatzraten erzielen möchten, sollten Sie mehrere Messagingfactorys verwenden.

Bei Erstellen einer Warteschlange oder eines Abonnementclients können Sie einen Empfangsmodus angeben: Peek/Lock oder Empfangen und Löschen. Der Standardempfangsmodus ist PeekLock. In diesem Modus sendet der Client eine Anforderung, um eine Nachricht von Servicebus zu empfangen. Nachdem der Client die Nachricht empfangen hat, sendet er eine Anforderung, um die Nachricht abzuschließen.

Wenn der Empfangsmodus auf ReceiveAndDelete festgelegt wird, werden beide Schritte in einer Anforderung kombiniert. Auf diese Weise wird die Gesamtanzahl der Vorgänge verringert, und der Gesamtnachrichtendurchsatz wird ggf. verbessert. Diese Leistungssteigerung bringt das Risiko von Nachrichtenverlusten mit sich.

Servicebus unterstützt keine Transaktionen für Empfangen-und-Löschen-Vorgänge. Außerdem ist Peek/Lock-Semantik für alle Szenarien erforderlich, in denen der Client eine Nachricht zurückstellen oder in die Warteschlange für unzustellbare Nachrichten verschieben möchte.

Durch clientseitige Batchverarbeitung kann eine Warteschlange oder ein Themaclient das Senden einer Nachricht für einen bestimmten Zeitraum verzögern. Wenn der Client weitere Nachrichten während dieses Zeitraums sendet, werden die Nachrichten in einem Batch übertragen. Durch clientseitige Batchverarbeitung wird außerdem bewirkt, dass eine Warteschlange/ein Abonnementclient mehrere Abschlussanforderungen als Batch in einer einzigen Anforderung verarbeitet. Batchverarbeitung ist nur für asynchrone Sende- und Abschlussvorgänge verfügbar. Synchrone Vorgänge werden sofort an den Servicebusdienst gesendet. Für Peek- oder Empfangsvorgänge tritt keine Batchverarbeitung auf, ebenso nicht clientübergreifend.

Wenn der Batch die maximale Nachrichtengröße überschreitet, wird die letzte Nachricht aus dem Batch entfernt, und der Client sendet den Batch sofort. Die letzte Nachricht wird zur ersten Nachricht im nächsten Batch. Ein Client verwendet standardmäßig ein Batchintervall von 20 ms. Sie können das Batchintervall ändern, indem Sie die Eigenschaft BatchFlushInterval festlegen, bevor Sie die Messagingfactory erstellen. Diese Einstellung wirkt sich auf alle Clients aus, die von dieser Factory erstellt werden. Wenn Sie Batverarbeitung deaktivieren möchten, legen Sie die Eigenschaft BatchFlushInterval auf TimeSpan.Zero fest. Beispiel:

MessagingFactorySettings mfs = new MessagingFactorySettings();
mfs.TokenProvider = tokenProvider;
mfs.NetMessagingTransportSettings.BatchFlushInterval = TimeSpan.FromSeconds(0.05);
MessagingFactory messagingFactory = MessagingFactory.Create(namespaceUri, mfs);

Batchverarbeitung wirkt sich nicht auf die Anzahl der abrechenbaren Messagingvorgänge aus und ist nur für das Servicebus Client-Protokoll verfügbar. Das HTTP-Protokoll unterstützt keine Batchverarbeitung.

Der Servicebusdienst fasst mehrere Nachrichten in einem Batch zusammen, wenn er in seinen internen Speicher schreibt, um den Durchsatz einer Warteschlange, eines Thema oder eines Abonnements zu erhöhen. Wenn diese Option für eine Warteschlange oder ein Thema aktiviert ist, wird das Schreiben von Nachrichten in den Speicher als Batchvorgang ausgeführt. Wenn diese Option für eine Warteschlange oder ein Abonnement aktiviert ist, wird das Löschen von Nachrichten aus dem Speicher als Batchvorgang ausgeführt. Wenn Speicherzugriff für eine Entität aktiviert ist, verzögert Servicebus einen Speicherschreibvorgang, der diese Entität betrifft, um bis zu 20 ms. Weitere Speichervorgänge, die in diesem Intervall auftreten, werden dem Batch hinzugefügt. Der Speicherbatchzugriff wirkt sich nur auf Sende- und Abschlussvorgänge aus, Empfangsvorgänge sind nicht betroffen. Speicherbatchzugriff ist eine Eigenschaft für eine Entität. Die Batchverarbeitung findet für alle Entitäten statt, die Speicherbatchzugriff aktivieren.

Beim Erstellen einer neuen Warteschlange, eines neuen Themas oder eines neuen Abonnements ist Speicherbatchzugriff standardmäßig aktiviert. Legen Sie zum Deaktivieren des Speicherbatchzugriffs die Eigenschaft EnableBatchedOperations auf false fest, bevor Sie die Entität erstellen. Beispiel:

QueueDescription qd = new QueueDescription();
qd.EnableBatchedOperations = false;
Queue q = namespaceManager.CreateQueue(qd);

Speicherbatchzugriff wirkt sich nicht auf die Anzahl der abrechenbaren Messagingvorgänge aus und ist eine Eigenschaft einer Warteschlange, eines Themas oder eines Abonnements. Er ist unabhängig vom Empfangsmodus und dem Protokoll, das zwischen einem Client und dem Servicebusdienst verwendet wird.

Durch Vorabruf kann die Warteschlange oder der Abonnementclient weitere Nachrichten aus dem Dienst laden, wenn er einen Empfangsvorgang ausführt. Der Client speichert diese Nachrichten in einem lokalen Cache. Die Größe des Caches wird durch die Eigenschaften PrefetchCount und PrefetchCount bestimmt. Jeder Client, der Vorabruf aktiviert, verwaltet seinen eigenen Cache. Ein Cache wird nicht clientübergreifend gemeinsam verwendet. Wenn der Client einen Empfangsvorgang initiiert, und sein Cache ist leer, überträgt der Dienst einen Nachrichtenbatch. Die Größe des Batches entspricht der Größe des Caches oder 256 KB (dabei gilt der kleinere Wert von beiden). Wenn der Client einen Empfangsvorgang initiiert, und der Cache enthält eine Nachricht, wird die Nachricht aus dem Cache entnommen.

Wenn ein Vorabruf für eine Nachricht stattfindet, sperrt der Dienst die vorabgerufene Nachricht. Auf diese Weise 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. Die vorabgerufene Kopie der Nachricht verbleibt im Cache. Der Empfänger, der die angelaufene zwischengespeicherte Kopie verarbeitet, empfängt eine Ausnahme, wenn er versucht, diese Nachricht abzuschließen. Die Nachrichtensperre läuft standardmäßig nach 60 Sekunden ab. Dieser Wert kann bis auf 5 Minuten erweitert werden. Damit die Verarbeitung abgelaufener Nachrichten verhindert wird, sollte die Cachegröße immer kleiner als die Anzahl der Nachrichten sein, die von einem Client innerhalb des Sperrentimeoutintervalls verarbeitet werden können.

Wenn der Standardsperrenablauf von 60 Sekunden verwendet wird, gilt als guter Wert für SubscriptionClient.PrefetchCount das 20-fache der maximalen Verarbeitungsraten aller Empfänger der Factory. Eine Factory erstellt z. B. 3 Empfänger. Jeder Empfänger kann bis z 10 Nachrichten pro Sekunde verarbeiten. Der Vorabruf sollte 20*3*10 =  600 nicht überschreiten. Standardmäßig ist QueueClient.PrefetchCount auf 0 festgelegt. Dies bedeutet, dass keine weiteren Nachrichten aus dem Dienst abgerufen werden.

Der Vorabruf von Nachrichten vergrößert den Gesamtdurchsatz für eine Warteschlange oder ein Abonnement, weil die Gesamtzahl der Nachrichtenvorgänge oder Roundtrips verringert wird. Das Abrufen der ersten Nachricht dauert jedoch (aufgrund der größeren Nachrichtengröße) länger. Das empfangen vorabgerufener Nachrichten ist schneller, weil diese Nachrichten bereits vom Client heruntergeladen wurden.

Die TTL-Eigenschaft (Time to Live, Gültigkeitsdauer) einer Nachricht wird durch den Server geprüft, wenn der Server die Nachricht an den Client sendet. Der Client überprüft die TTL-Eigenschaft der Nachricht beim Empfang nicht. Die Nachricht kann sogar selbst dann empfangen werden, wenn der TTL-Wert der Nachricht abgelaufen ist, während die Nachricht vom Client zwischengespeichert wurde.

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

Expressentitäten ermöglichen Szenarien mit hohem Durchsatz und geringerer Latenz. Mit Expressentitäten wird eine Nachricht, die an eine Warteschlange oder ein Thema gesendet wird, nicht sofort im Nachrichtenspeicher abgelegt. Stattdessen wird die Nachricht im Arbeitsspeicher zwischengespeichert. Wenn die Nachricht länger als einige Sekunden in der Warteschlange liegt, wird diese automatisch in den Datenspeicher geschrieben und somit vor Datenverlust geschützt. Durch das Ablegen der Nachricht im Cache des Arbeitsspeichers erhöht sich der Durchsatz und verringert sich die Latenz, da zu dem Zeitpunkt, zu dem die Nachricht gesendet wird, kein Zugriff auf nicht flüchtigen Speicher erfolgt. Nachrichten, die innerhalb von wenigen Sekunden abgerufen werden, werden nicht in den Nachrichtenspeicher geschrieben. Im folgenden Beispiel wird ein Expressthema erstellt:

TopicDescription td = new TopicDescription(TopicName);
td.EnableExpress = true;
namespaceManager.CreateTopic(td);

Wenn eine Nachricht, die wichtige Informationen enthält, die nicht verloren gehen dürfen, an eine Expressentität gesendet wird, kann der Absender Servicebus zwingen, die Nachricht sofort und dauerhaft im nicht flüchtigen Speicher abzulegen, indem er die Eigenschaft ForcePersistence auf true festlegt. Weitere Informationen finden Sie unter Neuerungen in der Version Azure SDK 2,3 (April 2014).

Intern verwendet Servicebus den gleichen Knoten und Messagingspeicher zum Verarbeiten und Speichern aller Nachrichten für eine Messagingentität (Warteschlange oder Thema). Eine partitionierte Warteschlange oder ein partitioniertes Thema ist im Gegensatz dazu auf mehrere Knoten und Messagingspeicher verteilt. Partitionierte Warteschlangen und Themen bieten nicht nur einen höheren Durchsatz als normale Warteschlangen und Themen, sie stellen auch exzellente Verfügbarkeit bereit. Wenn Sie eine partitionierte Entität erstellen möchten, legen Sie die Eigenschaft EnablePartitioning wie im folgenden Beispiel gezeigt auf true fest. Den Themenbereich zu partitionierten Entitäten finden Sie unter Partitionieren von Messagingentitäten.

// Create partitioned queue.
QueueDescription qd = new QueueDescription(QueueName);
qd.EnablePartitioning = true;
namespaceManager.CreateQueue(qd);

Wenn es nicht möglich ist, eine partitionierte Warteschlange oder ein partitioniertes Thema zu verwenden, oder die erwartete Last kann nicht von einer partitionierten Warteschlange oder einem partitionierten Thema verarbeitet werden, müssen Sie mehrere Messagingentitäten verwenden. Wenn mehrere Entitäten verwendet werden, erstellen Sie einen dedizierten Client für jede Entität, anstatt den gleichen Client für alle Entitäten zu verwenden.

In den folgenden Abschnitten werden typische Messagingszenarien beschrieben, und die bevorzugten Servicebus-Einstellungen werden erläutert. Durchsatzraten werden als gering (< 1 Nachricht/Sek.), mittel (≥ 1 Nachricht/Sek., < 100 Nachrichten/Sek.) und hoch (≥ 100 Nachrichten/Sek.) klassifiziert. Die Anzahl der Clients wird als klein (≤ 5), mittel (> 5, ≤ 20) und groß (> 20) klassifiziert.

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

  • Verwenden Sie eine partitionierte Warteschlange, um die Leistung und Verfügbarkeit zu optimieren.

  • Verwenden Sie zum Steigern der Gesamtsenderate in die Warteschlange mehrere Nachrichtenfactorys, um Absender zu erstellen. Verwenden Sie für jeden Absender asynchrone Vorgänge oder mehrere Threads.

  • Verwenden Sie zum Steigern der Gesamtempfangsrate von der Warteschlange mehrere Nachrichtenfactorys, um Empfänger zu erstellen.

  • Verwenden Sie asynchrone Vorgänge, um clientseitige Batchverarbeitung zu nutzen.

  • Legen Sie das Batchintervall auf 50 ms fest, um die Anzahl der Servicebus Client-Protokollübertragungen zu verringern. Wenn mehrere Absender verwendet werden, erhöhen Sie das Batchintervall auf 100 ms.

  • Lassen Sie die Batchverarbeitung des Speicherzugriffs aktiviert. Auf diese Weise wird die Gesamtrate gesteigert, mit der Nachrichten in die Warteschlange geschrieben werden können.

  • Legen Sie den Vorabrufwert auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Auf diese Weise wird die Anzahl der Servicebus Client-Protokollübertragungen verringert.

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

Verwenden Sie zum Erreichen des maximalen Durchsatzes für mehrere Warteschlangen die Einstellungen, die zum Maximieren des Durchsatzes einer einzelnen Warteschlange beschrieben wurden. Verwenden Sie außerdem verschiedene Factorys zum Erstellen von Clients, die Nachrichten an verschiedene Warteschlangen senden oder von verschiedenen Warteschlangen empfangen.

Ziel: Minimieren der End-to-End-Wartezeit einer Warteschlange oder eines Themas. Die Anzahl der Absender und Empfänger ist klein. Der Durchsatz de Warteschlange ist gering oder mittel.

  • Verwenden Sie eine partitionierte Warteschlange, um die Verfügbarkeit zu optimieren.

  • Deaktivieren Sie clientseitige Batchverarbeitung. Der Client sendet eine Nachricht sofort.

  • Deaktivieren Sie die Batchverarbeitung des Speicherzugriffs. Der Dienst schreibt die Nachricht sofort in den Speicher.

  • Wenn ein einzelner Client verwendet wird, legen Sie den Vorabrufwert auf das 20-fache der Verarbeitungsrate des Empfängers fest. Wenn mehrere Nachrichten gleichzeitig in der Warteschlange eingehen, überträgt das Servicebus Client-Protokoll diese alle gleichzeitig. 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 Vorabrufwert auf 0 fest. Auf diese Weise kann der zweite Client die zweite Nachricht abrufen, während der erste Client noch die erste Nachricht verarbeitet.

Ziel: 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.

Servicebus ermöglicht bis zu 100 gleichzeitige Verbindungen mit einer Entität. Für Warteschlangen wird diese Anzahl auf Absender und Empfänger aufgeteilt. Wenn alle 100 Verbindungen für Absender erforderlich sind, sollten Sie die Warteschlange durch ein Thema und ein einzelnes Abonnement ersetzen. Ein Thema akzeptiert bis zu 100 gleichzeitige Verbindungen von Absendern, und das Abonnement akzeptiert weitere 100 gleichzeitige Verbindungen von Empfängern. Wenn mehr als 100 gleichzeitige Absender erforderlich sind, sollten die Absender Nachrichten an das Servicebus-Protokoll über HTTP senden.

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

  • Verwenden Sie eine partitionierte Warteschlange, um die Leistung und Verfügbarkeit zu optimieren.

  • Wenn der Absender in einem anderen Prozess gespeichert ist, verwenden Sie nur eine einzelne Factory pro Prozess.

  • Verwenden Sie asynchrone Vorgänge, um clientseitige Batchverarbeitung zu nutzen.

  • Verwenden Sie das Batchstandardintervall von 20 ms, um die Anzahl der Servicebus Client-Protokollübertragungen zu verringern.

  • Lassen Sie die Batchverarbeitung des Speicherzugriffs aktiviert. Auf diese Weise wird die Gesamtrate gesteigert, mit der Nachrichten in die Warteschlange oder das Thema geschrieben werden können.

  • Legen Sie den Vorabrufwert auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Auf diese Weise wird die Anzahl der Servicebus Client-Protokollübertragungen verringert.

Ziel: 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.

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

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

  • Verwenden Sie eine partitionierte Warteschlange, um die Leistung und Verfügbarkeit zu optimieren.

  • Wenn der Empfänger in einem anderen Prozess gespeichert ist, verwenden Sie nur eine einzelne Factory pro Prozess.

  • Empfänger können synchrone oder asynchrone Vorgänge verwenden. Bei einer mittleren Empfangsrate eines einzelnen Empfängers wirkt sich clientseitige Batchverarbeitung einer Abschlussanforderung nicht auf den Empfängerdurchsatz aus.

  • Lassen Sie die Batchverarbeitung des Speicherzugriffs aktiviert. Dies verringert die Gesamtlast der Entität. Außerdem wird die Gesamtrate verringert, mit der Nachrichten in die Warteschlange oder das Thema geschrieben werden können.

  • Legen Sie den Vorabrufwert auf einen kleinen Wert fest (Beispiel: PrefetchCount = 10). Auf diese Weise wird verhindert, dass Empfänger im Leerlauf sind, während für andere Empfänger eine große Anzahl von Nachrichten zwischengespeichert wurde.

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

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

  • Verwenden Sie ein partitioniertes Thema, um die Leistung und Verfügbarkeit zu optimieren.

  • Verwenden Sie zum Steigern der Gesamtsenderate in das Thema mehrere Nachrichtenfactorys, um Absender zu erstellen. Verwenden Sie für jeden Absender asynchrone Vorgänge oder mehrere Threads.

  • Verwenden Sie zum Steigern der Gesamtempfangsrate aus einem Abonnement mehrere Nachrichtenfactorys, um Empfänger zu erstellen. Verwenden Sie für jeden Empfänger asynchrone Vorgänge oder mehrere Threads.

  • Verwenden Sie asynchrone Vorgänge, um clientseitige Batchverarbeitung zu nutzen.

  • Verwenden Sie das Batchstandardintervall von 20 ms, um die Anzahl der Servicebus Client-Protokollübertragungen zu verringern.

  • Lassen Sie die Batchverarbeitung des Speicherzugriffs aktiviert. Auf diese Weise wird die Gesamtrate gesteigert, mit der Nachrichten in das Thema geschrieben werden können.

  • Legen Sie den Vorabrufwert auf das 20-fache der maximalen Verarbeitungsraten aller Empfänger einer Factory fest. Auf diese Weise wird die Anzahl der Servicebus Client-Protokollübertragungen verringert.

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

Themen mit einer großen Anzahl von Abonnements weisen normalerweise einen geringen Gesamtdurchsatz auf, wenn alle Nachrichten an alle Abonnements weitergeleitet werden. Der Grund liegt darin, dass jede Nachricht viele Male empfangen wird und alle in einem Thema enthaltenen Nachrichten sowie dessen Abonnements alle im gleichen Speicher gespeichert werden. Es wird angenommen, dass die Anzahl der Absender und Empfänger pro Abonnement klein ist. Servicebus unterstützt bis zu 2000 Abonnements pro Thema.

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

  • Verwenden Sie ein partitioniertes Thema, um die Leistung und Verfügbarkeit zu optimieren.

  • Verwenden Sie asynchrone Vorgänge, um clientseitige Batchverarbeitung zu nutzen.

  • Verwenden Sie das Batchstandardintervall von 20 ms, um die Anzahl der Servicebus Client-Protokollübertragungen zu verringern.

  • Lassen Sie die Batchverarbeitung des Speicherzugriffs aktiviert. Auf diese Weise wird die Gesamtrate gesteigert, mit der Nachrichten in das Thema geschrieben werden können.

  • Legen Sie den Vorabrufwert auf das 20-fache der erwarteten Empfangsrate in Sekunden fest. Auf diese Weise wird die Anzahl der Servicebus Client-Protokollübertragungen verringert.

Anzeigen:
© 2014 Microsoft