Wie skalieren JMS-Selektoren mit der Warteschlangentiefe?

Question

Was ist die algorithmische Zeitkomplexität beim Anwenden von JMS-Selektoren beim Verbrauchen von Nachrichten aus einer Warteschlange in Bezug auf die Warteschlangentiefe n? Insbesondere ist es linear (O (n)) pro gelesen? Ist es implementierungsabhängig (auf dem JMS-Provider) und hängt es davon ab, welche Felder angefordert werden?

(wenn implementierungsabhängig, bin ich besonders interessiert an Websphere MQ und Solace Verhalten, aber ich begrüße Antworten, die mit einem bestimmten JMS-Anbieter, vor allem, wenn Sie Links zu Dokumentation beschreiben die Komplexität!).

Motivation: Jede Nachricht hat zwei Eigenschaften: eine invocationID und eine batchName. Ein Batch besteht aus mehreren Aufrufen. Clients möchten Nachrichten auf zwei Arten konsumieren. entweder durch invocationID oder durch batchName. An dem Punkt, an dem Nachrichten produziert werden, weiß ich nicht, mit welcher Methode sie konsumiert werden.

Diese durch Selektoren realisiert werden kann:

invocationID=42 

Oder

batchName="reconciliation" 

... und ich kann unter Verwendung der Korrelations-ID anstelle einer benutzerdefinierten Eigenschaft eines dieser nach oben beschleunigen, aber bin besorgt, dass der andere langsam bleiben wird.

Answer 1

According to the docs werden die Nachrichten nacheinander durchsucht. WMQ indexiert jedoch die Felder MessageID und CorrelID. Das Infocenter beschreibt das Verhalten wie folgt:

Das Auswählen von Nachrichten aus einer Warteschlange erfordert, dass WebSphere MQ sequenziell jede Nachricht in der Warteschlange untersucht. Nachrichten werden überprüft, bis eine Nachricht gefunden wird, die den Auswahlkriterien entspricht, oder weitere Nachrichten zu überprüfen sind. Daher leidet die Messaging-Leistung, wenn in tiefen Warteschlangen die Nachrichtenauswahl verwendet wird.

Um die Nachrichtenauswahl auf tiefe Warteschlangen zu optimieren, wenn eine Auswahl auf JMSCorrelationID oder JMSMessageID, verwenden Sie eine Auswahl Zeichenfolge der Form JMSCorrelationID = ... oder JMSMessageID = ... und Referenz basiert nur eine Eigenschaft.

Diese Methode bietet eine deutliche Verbesserung der Leistung für Auswahl auf JMSCorrelationID und bietet eine geringfügige Leistung Verbesserung für JMSMessageID.

Ich würde gerne mehr über die Anforderung zu Multiplex-Warteschlangen verstehen. Ein komplexer Selektor wirkt sich auf die Leistung einer beliebigen Implementierung aus, und die Alternative, mehrere offene Handles mit einfacheren Selektoren zu verwenden, unterscheidet sich nicht vom Anwendungscode, anstatt mehrere Warteschlangen zu verwenden. Für WMQ sind natürlich dynamische Warteschlangen oder viele fest definierte Warteschlangen überhaupt kein Problem. Sehr oft, wenn ich diese Anforderung sehe, kommt sie von Läden, die bestimmte andere Transporte benutzt haben, bei denen die Performance einen schweren Tauchgang mit vielen definierten Warteschlangen hat und es eine Annahme gibt, dass dies auch auf WMQ zutrifft. In anderen Fällen wurde die Anforderung mit Pub/Sub- und dauerhaften Abonnements erfüllt. Ich schlage nicht vor, dass es keine gültigen Fälle für diese Anforderung gibt, ich frage mich nur, was es antreibt.

Answer 2

Es hängt alles von der Implementierung ab. Viele JMS-Provider speichern Nachrichten in einer SQL-Datenbank, sodass sie SQL für die Selektorimplementierung verwenden können. In diesem Fall müssten Sie schauen, wie Ihr spezieller Fall in SQL abgebildet wird.

Wie für WebSphereMQ - die Selektor-Implementierung ist O (log n) für JMSMessageID = sth und JMSCorrelationID = sth, für die anderen habe ich keine spezifischen Kenntnisse. Aus Erfahrung sieht es jedoch nach O (n) aus.

Answer 3

Mit WebSphere MQ Version 7 wurde die Implementierung von Selektoren geändert. Mit einem v7 JMS-Client und einem v7-QueueManager erfolgt die Auswahlverarbeitung auf der QueueManager-Seite. Mit einem v6-JMS-Client-Modus (oder tatsächlich einem v7-Client, der im Migrationsmodus arbeitet) werden alle Nachrichten an den Client zur Verarbeitung weitergeleitet. Wenn die Trefferrate einer übereinstimmenden Nachricht niedrig war, gab es viel verschwendete Mühe. So

Mit v7 ist die Verarbeitung QueueManager Seite so getan, nur Nachrichten, die übereinstimmen, werden an den Client gesendet.

Denken Sie daran, dass der QueueManager komplexe Indizes von Nachrichteneigenschaften nicht wie eine Datenbank verwaltet. Die einfacheren Selektoren sind also besser.