W jaki sposób selektory JMS skalują się z głębokością kolejki?

Question

Jaka jest algorytmiczna złożoność czasowa stosowania selektorów JMS podczas pobierania wiadomości z kolejki, w odniesieniu do głębokości kolejki n? W szczególności czy jest liniowy (O (n)) na odczyt? Czy jest zależny od wdrożenia (od dostawcy JMS) i czy zależy od tego, które pola są wymagane?

(jeśli zależy od implementacji, szczególnie interesuje mnie zachowanie Websphere MQ i Solace, ale z przyjemnością przyjmuję odpowiedzi dotyczące konkretnego dostawcy JMS, szczególnie jeśli masz linki do dokumentacji opisującej złożoność!).

Motywacja: każda wiadomość ma dwie właściwości: invocationID i batchName. Partia składa się z kilku inwokacji. Klienci chcą konsumować wiadomości na jeden z dwóch sposobów; albo przez invocationID lub przez batchName. W momencie, w którym powstają wiadomości, nie wiem, jaką metodą zostaną one wykorzystane.

ten może być realizowany przez selektorów:

invocationID=42 

Or

batchName="reconciliation" 

... i mogę przyspieszyć jeden z nich się za pomocą identyfikatora korelacji zamiast właściwości niestandardowej, ale jestem zaniepokojony, że drugi pozostanie powolny.

Answer 1

According to the docs, wiadomości są wyszukiwane sekwencyjnie. WMQ jednak indeksuje pola MessageID i CorrelID. Centrum informacyjnym opisuje zachowanie się następująco:

Wybór wiadomości z kolejki wymaga WebSphere MQ do sekwencyjnego sprawdzać każdą wiadomość w kolejce. Wiadomości są sprawdzane, dopóki nie zostanie znaleziony komunikat zgodny z kryteriami wyboru lub nie ma więcej wiadomości do sprawdzenia. W związku z tym wydajność przesyłania komunikatów jest zagrożona, jeśli wybrano wybór wiadomości w głębokich kolejkach.

Aby zoptymalizować wybór wiadomość na głębokich kolejek gdy wybór jest oparty na JMSCorrelationID lub JMSMessageID użyć ciąg dobór formie JMSCorrelationID = ... lub JMSMessageID = ... i odniesienie tylko jedną właściwość.

Ta metoda zapewnia znaczącą poprawę wydajności w zakresie wyboru w JMSCorrelationID i oferuje marginalną poprawę ulepszenia dla JMSMessageID.

Chciałbym zrozumieć więcej na temat wymagań dotyczących kolejek multipleksowych. Złożony selektor wpłynie na wydajność na czyjejkolwiek implementacji, a alternatywa użycia wielu otwartych uchwytów za pomocą prostszych selektorów nie różni się od kodu aplikacji, niż przy użyciu wielu kolejek. Oczywiście dla WMQ dynamiczne kolejki lub wiele stale zdefiniowanych kolejek nie stanowi problemu. Bardzo często, gdy widzę ten wymóg, pochodzi on ze sklepów, które używały pewnych innych transportów, gdzie wydajność wymaga poważnego nurkowania z wieloma zdefiniowanymi kolejkami i istnieje założenie, że jest to prawdą również w przypadku WMQ. W innych przypadkach wymóg został spełniony z subskrypcjami Pub/Sub i trwałymi subskrypcjami. Nie sugeruję, że nie ma żadnych ważnych przypadków dotyczących tego wymogu, tylko zastanawiam się, co go napędza.

Answer 2

Wszystko zależy od implementacji. Wielu dostawców JMS przechowuje wiadomości w bazie danych SQL, aby mogli używać SQL do implementacji selektora. W takim przypadku musisz sprawdzić, w jaki sposób twój konkretny przypadek jest odwzorowany na SQL.

Co do WebSphereMQ - implementacja selektora to O (log n) dla JMSMessageID = sth i JMSCorrelationID = sth, dla innych nie posiadam żadnej konkretnej wiedzy. Z doświadczenia wynika jednak, że O (n).

Answer 3

W wersji 7 produktu WebSphere MQ zmieniono implementację selektorów. Za pomocą klienta JMS v7 i menedżera kolejki v7 QueueManager przetwarzanie wyboru jest wykonywane po stronie QueueManager. W przypadku klienta JMS v6 (lub w rzeczywistości klienta v7 pracującego w jego migracji) wszystkie komunikaty są przesyłane do klienta do przetwarzania. Jeśli współczynnik trafień pasującej wiadomości był niski, było dużo zmarnowanego wysiłku. Tak więc

Po v7 przetwarzanie jest wykonywane po stronie QueueManager, więc tylko te komunikaty, które są zgodne, są wysyłane do klienta.

Należy pamiętać, że QueueManager nie przechowuje złożonych indeksów właściwości wiadomości, tak jak baza danych. Więc prostsze selektory są lepsze.