Durchsatz des Nachrichtenflusses optimieren

Jeder von Ihnen entworfene Nachrichtenfluss muss einen vollständigen Satz von Verarbeitungsschritten für Nachrichten, die von einer bestimmten Quelle empfangen werden, enthalten. Durch diese Gestaltung können sehr komplexe Nachrichtenflüsse entstehen, die eine große Zahl von Knoten enthalten und Leistungseinbußen und mögliche Engpässe verursachen können. Eine Erhöhung der Anzahl von Nachrichtenflüssen zur Verarbeitung der Nachrichten bietet die Möglichkeit zur Parallelverarbeitung und dadurch einen verbesserten Durchsatz.

Sie können auch berücksichtigen, wie die vom Nachrichtenfluss aufgenommenen Aktionen festgeschrieben werden und in welcher Reihenfolge die Nachrichten verarbeitet werden sollen.

Berücksichtigen Sie folgende Optionen, um den Durchsatz des Nachrichtenflusses zu optimieren:

Mehrere Threads zur Verarbeitung von Nachrichten in einem einzelnen Nachrichtenfluss
Wenn Sie einen Nachrichtenfluss implementieren, startet der Broker automatisch für jeden in ihm enthaltenen Empfangsknoten eine Instanz des Nachrichtenflusses. Dieses Verhalten ist die Standardeinstellung. Wenn ein Nachrichtenfluss jedoch sehr viele Nachrichten bearbeitet, kann die Eingabequelle (z. B. die WebSphere MQ-Warteschlange) zu einem Engpass werden.

Sie können die Eigenschaft Zusätzliche Instanzen des implementierten Nachrichtenflusses in der BAR-Datei aktualisieren: Der Broker startet zusätzliche Kopien des Nachrichtenflusses in separaten Threads und ermöglicht dadurch eine Parallelverarbeitung. Diese Option ist die effektivste Methode zur Handhabung dieser Situation, wenn die Reihenfolge, in der Nachrichten verarbeitet werden, nicht so wichtig ist.

Wenn der Nachrichtenfluss Nachrichten aus einer WebSphere MQ-Warteschlange empfängt, können Sie die Reihenfolge, in der Nachrichten verarbeitet werden, beeinflussen, indem Sie die Eigenschaft Modus für Reihenfolge des MQInput-Knotens festlegen:

  • Wenn Sie die Eigenschaft Modus für Reihenfolge auf Nach Benutzer-ID setzen, stellt der Knoten sicher, dass Nachrichten von einem bestimmten Benutzer (identifiziert durch das Feld 'UserIdentifier' im MQMD) in der garantierten Reihenfolge verarbeitet werden. Die zweite Nachricht eines Benutzers wird nicht von der Instanz des Nachrichtenflusses verarbeitet, wenn eine vorherige Nachricht dieses Benutzers gerade noch von einer anderen Instanz im Nachrichtenfluss verarbeitet wird.
  • Wenn Sie Modus für Reihenfolge auf Nach WS-Reihenfolge setzen, verarbeitet der Knoten eine Nachricht nach der anderen, um die Reihenfolge beizubehalten, in der die Nachrichten aus der Warteschlange gelesen werden. Der Knoten verhält sich daher so, als ob Sie die Eigenschaft Zusätzliche Instanzen des Nachrichtenflusses auf null gesetzt hätten.

Für Publish/Subscribe-Anwendungen, die über eines der unterstützten Protokolle mit dem Broker kommunizieren, werden Nachrichten zu einem angegebenen Thema von den Brokern in der Reihenfolge veröffentlicht, in der sie von der Veröffentlichungskomponente empfangen werden (vorbehaltlich einer Änderung der Reihenfolge abhängig von der Nachrichtenpriorität, falls anwendbar). Dies bedeutet, dass jeder Subskribent Nachrichten von einem bestimmten Broker, zu einem bestimmten Thema oder von einer bestimmten Veröffentlichungskomponente in der Reihenfolge empfängt, in der sie von der jeweiligen Veröffentlichungskomponente veröffentlicht werden.

Gelegentlich werden Nachricht jedoch nicht in der Reihenfolge zugestellt. Dies kann beispielsweise dann passieren, wenn ein Link im Netz fehlschlägt und nachfolgende Nachrichten von einem anderen Link weitergeleitet werden.

Wenn Sie sicherstellen müssen, dass die Reihenfolge der empfangenen Nachrichten erhalten bleibt, können Sie für jede veröffentlichte Nachricht entweder den Parameter SeqNum (Folgenummer) oder den Parameter PubTime (Zeitmarke für Veröffentlichung) des Befehls Publish verwenden, um die Veröffentlichungsreihenfolge zu berechnen.

Beginn der ÄnderungWeitere Informationen zu den für alle MQI- und AMI-Benutzer empfohlenen Verfahren finden Sie in den Handbüchern Application Programming Reference und Application Programming Guide im WebSphere MQ Version 6 Information Center online oder (bei WebSphere MQ Version 5.3) in den Handbüchern Application Programming Guide und Application Programming Reference in der Webseite der Bibliothek zu WebSphere MQ für Programme, die für die MQI geschrieben wurden, und im Handbuch WebSphere MQ Application Messaging Interface für Programme, die für AMI geschrieben wurden. Ende der Änderung

Das Handbuch WebSphere MQ Application Messaging Interface ist auf der Webseite der Bibliothek zu WebSphere MQ (Liste unter Version 5.3) oder unter SupportPac MA0F auf der Webseite mit WebSphere MQ SupportPacs verfügbar.

Beginn der ÄnderungInformationen finden Sie auch im Abschnitt Publish/Subscribe User's Guide im WebSphere MQ Version 6 Information Center online oder (bei WebSphere MQ Version 5.3) im Publish/Subscribe User's Guide auf der Webseite der Bibliothek zu WebSphere MQ.Ende der Änderung

WebSphere MQ Everyplace und SCADA-Anwendungen verwenden eine andere Methode zur Sortierung von Nachrichten als unter WebSphere MQ Mobile Transport bzw. WebSphere MQ Telemetry Transport beschrieben. Der Broker bietet keine Möglichkeit zum Sortieren von Nachrichten, die über WebSphere MQ Web Services Transport,WebSphere MQ Real-time Transport oder WebSphere MQ Multicast Transport empfangen werden.

Mehrere Kopien des Nachrichtenflusses in einem Broker
Sie können auch mehrere Kopien desselben Nachrichtenflusses in unterschiedlichen Ausführungsgruppen desselben Brokers einsetzen. Dies hat ähnliche Auswirkungen wie die Erhöhung der Anzahl der Verarbeitungsthreads in einem einzelnen Nachrichtenfluss, ist jedoch in der Regel mit einer geringeren Leistungszunahme verbunden.

Bei dieser Option kann die Verarbeitungsreihenfolge der Nachrichten nicht mehr bestimmt werden. Der Grund hierfür ist, dass bei mehreren aktiven Kopien des Nachrichtenflusses im Broker jede der Kopien eine Nachricht zur selben Zeit aus derselben Warteschlange verarbeiten kann. Die Zeit für die Verarbeitung einer Nachricht kann variieren. Wenn mehrere Nachrichtenflüsse auf dieselbe Warteschlange zugreifen, kann es deshalb vorkommen, dass Nachrichten aus der Eingabequelle in einer Zufallsreihenfolge gelesen werden. Die von den Nachrichtenflüssen erstellte Reihenfolge der Nachrichten entspricht dann möglicherweise nicht der Reihenfolge der ursprünglichen Nachrichten.

Stellen Sie sicher, dass Anwendungen, die Nachrichten von diesen Nachrichtenflüssen empfangen, auch Nachrichten außerhalb der Reihenfolge akzeptieren.

Kopien des Nachrichtenflusses in mehreren Brokern
Sie können mehrere Kopien desselben Nachrichtenflusses in unterschiedlichen Brokern einsetzen. Diese Option erfordert Änderungen in der Konfiguration, weil Sie sicherstellen müssen, dass Anwendungen, die Nachrichten an den Nachrichtenfluss liefern, ihre Nachrichten in die richtige Eingabewarteschlange oder den richtigen Port stellen können. Sie können diese Änderungen in vielen Fällen beim Einsetzen des Nachrichtenflusses durchführen, indem Sie die konfigurierbaren Eigenschaften des Nachrichtenflusses festlegen.
Umfang des Nachrichtenflusses
Unter bestimmten Bedingungen kann es sinnvoll sein, einen einzelnen Nachrichtenfluss in mehrere unterschiedliche Flüsse aufzuteilen, um den Arbeitsumfang für jeden einzelnen Nachrichtenfluss zu verringern. Beachten Sie bei der Aufteilung Ihres Nachrichtenflusses jedoch, dass die separaten Nachrichtenflüsse nicht in derselben Arbeitseinheit ausgeführt werden können. Falls Sie bei einem Nachrichtenfluss transaktionsorientierte Aspekte berücksichtigen müssen (z. B. die Aktualisierung mehrerer Datenbanken), stellt diese Option keine geeignete Lösung dar.

Die folgenden zwei Beispiele zeigen, wann das Aufteilen eines Nachrichtenflusses sinnvoll sein kann:

  1. In einem Nachrichtenfluss, der einen RouteToLabel-Knoten verwendet, hat sich die Eingabewarteschlange zu einem Engpass entwickelt. Sie können eine andere Kopie des Nachrichtenflusses in einer zweiten Ausführungsgruppe einsetzen. Dies ist jedoch keine geeignete Lösung, wenn alle Nachrichten in der Reihenfolge verarbeitet werden sollen, in der sie in der Warteschlangen stehen. Es besteht die Möglichkeit, alle Zweige des Nachrichtenflusses, die mit einem Label-Knoten beginnen, abzutrennen, indem jedem dieser Zweige eine Eingabewarteschlange und ein Empfangsknoten zur Verfügung gestellt werden. Dies kann sinnvoll sein, weil die Nachricht, wenn sie vom RouteToLabel-Knoten an den relevanten Label-Knoten weitergeleitet wird, in einem gewissen Grad von allen anderen Nachrichten unabhängig ist.

    Gegebenenfalls müssen Sie außerdem eine weitere Eingabewarteschlange und einen weiteren Empfangsknoten zur Ausführung allgemeiner Verarbeitungsschritte bereitstellen, mit dem die Zweige des Label-Knotens eine Verbindung herstellen, nachdem eine einmalige Verarbeitung erfolgt ist.

  2. Wenn Sie einen Nachrichtenfluss zur Verarbeitung sehr großer Nachrichten, die erhebliche Zeit in Anspruch nehmen, einsetzen, haben Sie folgende Möglichkeiten:
    1. Erstellen Sie weitere Kopien des Nachrichtenflusses, die eine andere Eingabewarteschlange verwenden (im Nachrichtenfluss selbst konfigurierbar oder durch Ändern der betreffenden Eigenschaften beim Einsetzen des Nachrichtenflusses).
    2. Konfigurieren Sie Aliasnamen für die WebSphere MQ-Warteschlangen, um Nachrichten von einigen Anwendungen an die alternative Warteschlange und den alternativen Nachrichtenfluss umzuleiten.

    Sie können auch einen neuen Nachrichtenfluss erstellen, der die Funktion des ursprünglichen Nachrichtenflusses nachbildet ,aber nur große Nachrichten, die sofort vom ursprünglichen Nachrichtenfluss an ihn weitergegeben werden, verarbeitet, wobei Sie diesen dahingehend geändert haben, dass er die Größe der Eingangsnachrichten überprüft und die großen Nachrichten umleitet.

Häufigkeit von Festschreibungen
Wenn ein Nachrichtenfluss Nachrichten in einer WebSphere MQ-Warteschlange empfängt, können Sie für einige Nachrichtenflussszenarios den Durchsatz verbessern, indem Sie die zugehörigen Standardeigenschaften ändern, nachdem Sie den Nachrichtenfluss zu einer BAR-Datei hinzugefügt haben. (Diese Optionen sind nicht verfügbar, wenn die Eingangsnachrichten von einem anderen Empfangsknoten entgegengenommen werden; Festschreibungen in solchen Nachrichtenflüssen werden für jede einzelne Nachricht durchgeführt.)

Die folgenden Eigenschaften steuern die Häufigkeit, mit der der Nachrichtenfluss Transaktionen festschreibt:

  • Festschreibungszähler. Diese Eigenschaft gibt die Anzahl der Nachrichten an, die aus der Eingabewarteschlange verarbeitet werden, bevor ein MQCMIT-Befehl ausgegeben wird.
  • Festschreibungsintervall. Diese Eigenschaft gibt das Zeitintervall an, nach dessen Ablauf ein MQCMIT gestartet wird.
Zugehörige Konzepte
Nachrichtenflüsse - Übersicht
Übersicht über die Implementierung
Zugehörige Tasks
Reaktionszeiten von Nachrichtenflüssen optimieren
Nachrichtenflüsse erstellen
Nachrichtenflussinhalte definieren
Konfigurierbare Eigenschaften bearbeiten
Zugehörige Verweise
Integrierte Knoten
Konfigurierbare Nachrichtenflusseigenschaften
Beginn der ÄnderungNachricht veröffentlichenEnde der Änderung
Zugehörige Informationen
WebSphere MQ Version 6 Information Center online
WebSphere MQ-Bibliothekswebseite
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:01

ac00350_