In che modo i selettori JMS ridimensionano con la profondità della coda?

Question

Qual è la complessità temporale algoritmica dell'applicazione dei selettori JMS quando si utilizzano messaggi da una coda, in relazione alla profondità della coda n? In particolare, è lineare (O (n)) per lettura? È dipendente dall'implementazione (sul provider JMS) e dipende da quali campi vengono richiesti?

(se l'implementazione dipende, sono particolarmente interessato a Websphere MQ e al comportamento di Solace, ma accolgo con favore le risposte che riguardano qualsiasi particolare provider JMS, specialmente se si dispone di collegamenti alla documentazione che descrive la complessità!).

Motivazione: ogni messaggio ha due proprietà: una invocationID e batchName. Un lotto consiste di diverse invocazioni. I clienti desiderano consumare messaggi in uno dei due modi; o dal invocationID o dal batchName. Al punto che i messaggi vengono prodotti, non so con quale metodo verranno consumati.

Questo può essere attuata attraverso selettori:

invocationID=42 

O

batchName="reconciliation" 

... e posso accelerare uno di questi in su utilizzando l'ID di correlazione invece di una proprietà personalizzata, ma sono preoccupato che l'altro rimanga lento.

Answer 1

According to the docs, i messaggi vengono cercati in sequenza. WMQ tuttavia indicizza i campi MessageID e CorrelID. L'Infocenter descrive il comportamento come segue:

Selezione di messaggi da una coda richiede WebSphere MQ in sequenza ispezionare ogni messaggio sulla coda. I messaggi vengono controllati fino a quando viene trovato un messaggio che corrisponde ai criteri di selezione o non ci sono più messaggi da esaminare. Pertanto, le prestazioni della messaggistica subiscono se la selezione del messaggio viene utilizzata nelle code profonde.

Per ottimizzare la selezione dei messaggi sulle code profonde quando la selezione è basata su JMSCorrelationID o JMSMessageID, utilizzare una stringa di selezione della forma JMSCorrelationID = ... o JMSMessageID = ... e di riferimento una proprietà.

Questo metodo offre un miglioramento significativo delle prestazioni per la selezione di su JMSCorrelationID e offre un miglioramento marginale delle prestazioni per JMSMessageID.

Mi piacerebbe capire di più sul requisito delle code multiplex. Un selettore complesso influenzerà le prestazioni sull'implementazione di chiunque e l'alternativa di utilizzare più handle aperti con selettori più semplici non è diversa dal codice dell'app rispetto all'utilizzo di più code. Naturalmente per WMQ, le code dinamiche o molte code definite in modo permanente non sono affatto un problema. Molto spesso, quando vedo questo requisito, proviene da negozi che hanno utilizzato alcuni altri trasporti in cui le prestazioni subiscono un'immersione grave con molte code definite e si presume che ciò sia vero anche per WMQ. In altri casi il requisito è stato soddisfatto con Pub/Sub e abbonamenti durevoli. Non sto suggerendo che non ci siano casi validi per questo requisito, basta chiedersi che cosa lo sta guidando.

Answer 2

Tutto dipende dall'implementazione. Molti provider JMS memorizzano i messaggi in un database SQL in modo che possano utilizzare SQL per l'implementazione del selettore. In questo caso dovresti vedere come il tuo caso particolare è mappato in SQL.

Come per WebSphereMQ - l'implementazione del selettore è O (log n) per JMSMessageID = sth e JMSCorrelationID = sth, per gli altri non ho una conoscenza specifica. Dall'esperienza sembra però O (n).

Answer 3

Con WebSphere MQ versione 7 è stata modificata l'implementazione dei selettori. Con un client JMS v7 e QueueManager v7, l'elaborazione della selezione viene eseguita dal lato QueueManager. Con un client JMS v6 (o di fatto un client v7 che lavora nella sua migrazione), tutti i messaggi vengono trasferiti al client fino all'elaborazione. Se il tasso di successo di un messaggio di corrispondenza era basso, c'era un grande sforzo sprecato. Quindi

Con v7 l'elaborazione viene eseguita lato QueueManager in modo che solo i messaggi che corrispondono vengono inviati al client.

Ricordare che QueueManager non gestisce indici complessi delle proprietà dei messaggi come farebbe un database. Quindi i selettori più semplici sono i migliori.