Как шкалы JMS масштабируются с глубиной очереди?

Какова алгоритмическая временная сложность применения JMS-селекторов при потреблении сообщений из очереди по отношению к глубине очереди n? В частности, является ли он линейным (O (n)) на чтение? Это зависит от реализации (от поставщика JMS) и зависит от того, какие поля запрашиваются?

(если зависит от реализации, меня особенно интересуют поведение WebSphere MQ и Solace, но я приветствую ответы, которые касаются любого конкретного JMS-провайдера, особенно если у вас есть ссылки на документацию, описывающую сложность!).

Мотивация: каждое сообщение имеет два свойства: a invocationID и a batchName. Пакет состоит из нескольких вызовов. Клиенты хотят потреблять сообщения одним из двух способов; либо invocationID, либо batchName. В момент создания сообщений я не знаю, каким способом они будут потребляться.

Это может быть реализовано с помощью селекторов:

invocationID=42

или

batchName="reconciliation"

... и я могу ускорить один из них, используя идентификатор корреляции вместо настраиваемого свойства, но я обеспокоен тем, что другой будет оставаться медленным.

Ответы

Ответ 1

В соответствии с документами, поиск сообщений выполняется последовательно. Однако WMQ индексирует поля MessageID и CorrelID. Инфоцентр описывает поведение следующим образом:

Для выбора сообщений из очереди требуется, чтобы WebSphere MQ последовательно проверять каждое сообщение в очереди. Сообщения проверяются до тех пор, пока отображается сообщение, соответствующее критериям выбора, или нет больше сообщений для изучения. Следовательно, производительность обмена сообщениями страдает, если выбор сообщения используется в глубоких очередях.

Чтобы оптимизировать выбор сообщений в глубоких очередях при выборе на JMSCorrelationID или JMSMessageID, используйте строку выбора форма JMSCorrelationID =... или JMSMessageID =... и только ссылка одно свойство.

Этот метод обеспечивает значительное улучшение производительности для выбор на JMSCorrelationID и предлагает предельную производительность улучшение для JMSMessageID.

Я хотел бы больше узнать о требованиях к мультиплексированию очередей. Сложный селектор будет влиять на производительность для любой реализации, и альтернатива использованию нескольких открытых дескрипторов с более простыми селекторами не отличается от кода приложения, чем использование нескольких очередей. Разумеется, для WMQ динамические очереди или много постоянно заданных очередей не проблема. Очень часто, когда я вижу это требование, это происходит из магазинов, которые использовали некоторые другие транспорты, где производительность занимает серьезное погружение с большим количеством заданных очередей, и есть предположение, что это верно и для WMQ. В других случаях требование было удовлетворено с помощью Pub/Sub и долговременной подписки. Я не предполагаю, что для этого требования нет действительных случаев, просто интересно, что его заставляет.

Ответ 2

Все зависит от реализации. Многие поставщики JMS хранят сообщения в базе данных SQL, поэтому они могут использовать SQL для реализации селектора. В этом случае вам придется посмотреть, как ваш конкретный случай отображается в SQL.

Что касается WebSphereMQ - реализация селектора - это O (log n) для JMSMessageID = sth и JMSCorrelationID = sth, для остальных у меня нет конкретных знаний. По опыту это выглядит как O (n).

Ответ 3

С версией 7 WebSphere MQ была изменена реализация селекторов. С помощью клиента v7 JMS и v7 QueueManager обработка выбора выполняется со стороны QueueManager. С клиентом v6 JMS (или, фактически, с клиентом, работающим с ним в режиме миграции) все сообщения передаются клиенту для обработки. Если скорость попадания соответствующего сообщения была низкой, было потрачено много усилий. Итак,

С v7 обработка выполняется стороной QueueManager, поэтому только сообщения, которые соответствуют, отправляются клиенту.

Имейте в виду, что QueueManager не поддерживает сложные индексы свойств сообщений в качестве базы данных. Таким образом, более простые селектора лучше.