Является ли MQ публиковать / подписывать специфичный для домена интерфейс, как правило, быстрее, чем точка-точка?

Question

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

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

В настоящее время нам нужно что-то подобное для связи с MQ:

responseObject getInfo(requestObject){
    code to send message to MQ
    code to retrieve message from MQ
}

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

На данный момент я могу придумать 2 возможных сценария.

1) Внутри приложения создать группу потоков, которые будут выполнять транспортный адаптер для каждой учетной записи. Затем получите данные по каждой задаче. Я предпочитаю этот метод, но некоторые члены команды утверждают, что транспортный уровень - лучшее место для таких изменений, и мы должны поместить дополнительную нагрузку на MQ вместо нашего приложения.

2) Переработать транспортный уровень для использования модели публикации / подписки. В идеале я хочу что-то вроде этого:

void send (requestObject){
  code to send message to MQ
}

responseObject receive()
{
  code to retrieve message from MQ
}

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

Мой вопрос, это будет намного быстрее, чем текущий последовательный поиск?

Answer 1

Заголовок вопроса обозначает это как выбор между P2P и pub / sub, но тело вопроса обрамляет его как выбор между потоковой и конвейерной обработкой. Это две совершенно разные вещи.

Любой предоставленный фрагмент кода может так же легко использовать P2P или pub / sub для размещения и получения сообщений. Решение должно основываться не на скорости, а на том, требует ли данный интерфейс доставки одного сообщения нескольким получателям. Если ответ «нет», вы, вероятно, захотите придерживаться метода «точка-точка», независимо от модели потоков вашего приложения.

И, кстати, ответ на поставленный в заголовке вопрос - «нет». Когда вы используете модель «точка-точка», ваши сообщения немедленно преобразуются в пункт назначения или очередь передачи, и WebSphere MQ направляет их оттуда. С pub / sub ваше сообщение передается внутреннему процессу брокера, который разрешает ноль во многих возможных местах назначения. Только после этого шага опубликованное сообщение помещается в очередь, где на оставшуюся часть пути оно обрабатывается, как и любое другое сообщение «точка-точка». Хотя pub / sub обычно не заметно медленнее, чем точка-точка, путь к коду длиннее, и, следовательно, при прочих равных условиях, это увеличит задержку.

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

Ключом к этому вопросу является то, имеют ли сообщения сходство друг с другом, для упорядочения зависимостей или для экземпляра приложения или потока, который их создал. Например, если я отвечаю на запрос HTTP запросом / ответом, то поток, присоединенный к сеансу HTTP, вероятно, должен быть тем, который получает ответ. Но если ответ действительно асинхронный, и все, что мне нужно сделать, это обновить базу данных данными ответа, тогда полезно иметь отдельные потоки запросов и ответов.

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

Дополнительную информацию по этим вопросам см. В следующей статье: Миссия: обмен сообщениями: миграция, отработка отказа и масштабирование в кластере WebSphere MQ

Кроме того, перейдите на страницу WebSphere MQ SupportPacs и найдите Performance SupportPac для вашей платформы и версии WMQ. Это те, имена которых начинаются с MP **. Они покажут вам характеристики производительности в зависимости от количества подключенных экземпляров приложения.

Answer 2

Не похоже, что вы думаете об этом правильно.Независимо от используемой вами модели (двухточечная или публикация / подписка), если ваша производительность ограничена медленной серверной системой, ни одна из них не поможет ускорить процесс.Однако если теоретически вы могли бы выдавать более одного запроса за раз для серверной системы и ожидать ускорения, то вам все равно неважно, выполняете ли вы функцию «точка-точка» или публикуете / подписываетесь.Что вас действительно волнует, так это синхронность и асинхронность.

Ваш текущий подход к получению данных явно синхронен: вы отправляете сообщение с запросом и ждете соответствующего ответного сообщения.Вы могли бы сделать ваше сообщение асинхронным, если бы вы просто отправляли все сообщения запроса подряд (возможно, в цикле) одним методом, а затем имели отдельный метод (предпочтительно в другом потоке), отслеживающий входящую тему для ответов.Это гарантирует, что ваш код больше не будет блокироваться по отдельным запросам.(Это примерно соответствует варианту 2, хотя и без pub / sub.)

Я думаю, что вариант 1 может стать довольно громоздким, в зависимости от того, сколько запросов вы фактически должны сделать, хотя он тоже может быть реализован безпереключение на паб / подканал.

Answer 3

Переработанный подход будет использовать меньше потоков.Будет ли это ускорять работу приложения, зависит от того, замедляют ли вас издержки на управление большим количеством потоков.Если у вас меньше 1000 потоков (это очень и очень грубая оценка порядка!), Я думаю, это не так.Если у вас есть больше, это вполне может быть.