Производительность сообщений JMS: множество тем/очереди или расширенная фильтрация (селектор сообщений)

Я работаю над проектом, который будет активно использовать JBoss Messaging (JMS). Мне поручено создать простую в использовании оболочку для обмена сообщениями для других разработчиков, и я думаю об использовании JMS Message Selectors, чтобы обеспечить технологию фильтрации, чтобы избежать ненужной отправки сообщений до минимума. Мне любопытно, есть ли у кого-нибудь опыт в отношении производительности? Я боюсь, что провайдер JMS может увязнуть с Селекторами сообщений, эффективно побеждая целую цель. Было бы гораздо лучше, чем создавать длинный список тем/очередей для каждого типа сообщений.

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

Ответ 1

Как упоминал Мартин, по умолчанию большинство реализаций JMS будут обрабатывать селектора сообщений на клиенте, если они не являются частью долговременной подписки, когда большинство реализаций JMS будут обрабатывать их на сервере, а также избегать слишком большого количества сообщений, значительное сокращение количества сообщений, которые проходят через селектор. Некоторые системы (например, SonicMQ) позволяют указать, что селектора сообщений должны обрабатываться на сервере, что является хорошим вариантом в случае, когда у вашего избыточного ЦП имеется доступ к вашим брокерам сообщений, но не к вашим потребителям.

Имейте в виду, что, хотя выбор на основе темы обычно быстрее, это может быть довольно громоздким, потому что если вы хотите слушать 5 разных вещей, у вас должно быть 5 разных MessageConsumers. Каждый из них в наивной реализации драйвера - это другой поток, который может начать складываться. По этой причине часто бывает полезно поддерживать как публикацию, так и некоторые клиенты могут слушать только те темы, которые они хотят, а другие могут слушать иерархии тем, которые они хотят (например, foo. #), С помощью селекторов сообщений (или кода- основанные на селекторах).

Однако вы всегда должны тестировать свое приложение и своего брокера. Каждый брокер обрабатывает ситуацию по-разному, и каждое приложение работает по-разному. Вы не можете просто сказать "всегда использовать технику X", потому что каждый метод обработки сообщений, ориентированный на клиента, имеет разные компромиссы. Бенчмарк, контрольный ориентир, контрольный показатель.

Одна вещь, которую следует учитывать с селекторами сообщений, заключается в том, что они не являются динамически изменчивыми, поэтому у вас есть возможность потерять сообщения или вручную управлять сложным сценарием переключения. Представьте себе следующий пример использования:

Вы слушаете селектор сообщений формы (Тикер в ( "CSCO", "MSFT" ))
Пользователь хочет начать прослушивание AAPL
Вы должны закрыть старый MessageConsumer и запустить новый с селектором в форме (тикер в ( "CSCO", "MSFT", "AAPL" ))
Во время переключения вы либо теряете сообщения (потому что вы закрываете старый, прежде чем запускать новый), либо вам нужно вручную удалить дубликаты (потому что у вас есть новый, который был запущен до старого)

Ответ 2

Мои два цента:

Я задал себе тот же вопрос, касающийся ActiveMQ.

Во-первых, я не использовал селекторов и создал множество тем. Производительность была ужасной, так как брокер не мог обрабатывать 100 тем без большого количества ресурсов.
тогда я использовал комбинацию тем/селекторов. У меня сейчас небольшое количество тем. Отбор работает хорошо. Но нагрузка не очень тяжелая, не более 10 msg/s

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

Ответ 3

Разная реализация, но я пройду разговор, который у меня был с архитектором высокого уровня для продуктов BEA JMS. Я упомянул об использовании селекторов, и он прокомментировал что-то вроде строк "отлично, если вы не хотите, чтобы он выполнял".

В нашем приложении было 10 сообщений/сек. Вероятно, он видел жесткие проблемы со 100-1000 в секунду. Если вы не находитесь в этих более высоких диапазонах или не используете очень медленное оборудование, многие очереди/темы или селектора, вероятно, будут работать нормально.

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

Ответ 4

Из моего опыта реализации JBoss MQ для фильтрации сообщений использовались клиенты. Очевидно, это означает, что каждое сообщение в теме по-прежнему относится к каждому получателю, даже если они игнорируют его. С другой стороны, разные очереди и темы на сервере влияют на производительность сервера.

Я бы сказал, что распространение селекторов повлияет на загрузку клиентов и сети, а распространение тем и очередей повлияет на загрузку сервера. Очевидно, что сетевая нагрузка, потребительская нагрузка сообщения и поставщик сообщений все различаются по-разному.

Помимо простого случая, обертки становятся сложными; Я бы рекомендовал вам обернуть обработку ошибок и JMS API в простой API-интерфейс передачи сообщений, концептуально структурированный для удовлетворения ваших конкретных потребностей. Затем, под обложками, вы можете перейти на любой из вышеперечисленных конструкций с минимальной суматохой.

Ответ 5

Хм, у меня есть сомнения. JMS довольно прост в использовании. Я видел, как это пробовало, и более простое в использовании решение было сложнее использовать и глючить.