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

Question

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

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

Answer 1

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

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

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

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

1. Вы прослушиваете селектор сообщений в форме (тикер в ('CSCO', 'MSFT'))
2. Пользователь хочет начать слушать AAPL
3. Вы должны закрыть старый MessageConsumer и запустить новый с помощью селектора в форме (Ticker in ('CSCO,' MSFT ',' AAPL '))
4. Во время переключения вы либо теряете сообщения (потому что закрыли старое перед запуском нового), либо вам приходится вручную удалять дубликаты (потому что у вас новый запущен раньше старого)

Answer 2

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

Я задал себе точно такой же вопрос относительно ActiveMQ.

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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