Проблема с производительностью EMS

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

Я использую Tibco EMS для связи между клиентом и сервером. Предоставляется клиентская библиотека, которая обертывает логику на стороне клиента (например, конвертирует данные в сообщение EMS и т. Д.) И отправляет запрос в очередь запросов. Серверная часть обрабатывает запрос и отправляет ответ в отдельную очередь. Это прекрасно работает.

Сторона сервера многопоточная. Новый поток создается при получении нового входящего запроса. Таким образом, запросы обрабатываются одновременно.

На стороне сервера используется одно единственное соединение EMS с сервером EMS. Однако, поскольку сеанс EMS не является потокобезопасным, если я хочу иметь возможность записывать ответ в очередь EMS в каждом потоке, мне нужно создать один сеанс для каждого потока, используя connectionFactory. Это ухудшило производительность.

Время, затрачиваемое на трафик, составляет около 3-4 мс, т.е. время между отправкой запроса и получением ответа составляет около 5-6 мс (3-4 мс для транспортировки, маршала / демаршала, 2 мс для расчета).

Есть ли какое-нибудь решение, которое позволяет мне одновременно отправлять в очередь EMS без создания двух больших объектов JMS?

Есть ли еще какие-то важные правила, которые мне нужно соблюдать для дальнейшей оптимизации сервиса? Некоторые основные рекомендации по оптимизации уже выполнены:

  1. Используйте CachedConnectionPool
  2. Отправить сообщение JMS как NON_PERSISTANT
  3. Используйте одно соединение EMS для всех запросов.

Большое Вам спасибо.


java concurrency jms tibco-ems ems
person Kevin    schedule 29.01.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Поведение, которое вы испытываете, не характерно для EMS. Поведение продиктовано самой спецификацией JMS. Вот выдержка из раздела 2.8 Спецификации JMS:

Есть две причины для ограничения одновременного доступа к сеансам. Во-первых, сеансы - это объект JMS, поддерживающий транзакции. Реализовать многопоточные транзакции очень сложно. Во-вторых, сеансы поддерживают асинхронное потребление сообщений. Важно, чтобы JMS не требовал, чтобы клиентский код, используемый для асинхронного приема сообщений, мог обрабатывать несколько одновременных сообщений. Кроме того, если сеанс был настроен с несколькими асинхронными потребителями, важно, чтобы клиент не был вынужден обрабатывать случай, когда эти отдельные потребители выполняются одновременно. Эти ограничения упрощают использование JMS для типичных клиентов. Более сложные клиенты могут получить желаемый параллелизм, используя несколько сеансов.

Если вы хотите избежать создания (и уничтожения) такого количества объектов, вы можете заранее создать пул потоков и заранее выделить сеанс каждому потоку.

person nochum    schedule 30.01.2015