Какие шаги можно предпринять, чтобы оптимизировать Tibco JMS для повышения производительности?

Question

Мы используем систему с высокой пропускной способностью, которая использует tibco-ems JMS для передачи большого количества сообщений на наш главный сервер и с него на наши клиентские соединения.Мы сделали некоторую статистику и определили, что JMS является причиной большой задержки.Как мы можем сделать Tibco JMS более производительным?Есть ли какие-либо ресурсы, которые дают хорошее обсуждение по этой теме.

Answer 1

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

Это актуально, если:

• сбои редки (так как восстановление занимает время)
• Вы можете легко обнаружить сбой
• вы можете обрабатывать дубликаты сообщений (вы можете не знать точно, какие сообщения были доставлены до сбоя

EMS также предоставляет некоторые механизмы, которые являются устойчивыми, но менее пуленепробиваемыми, чем классическая гарантированная доставка К ним относятся:

• вместо доставки сообщения «ровно один раз» вы можете использовать доставку «хотя бы один раз» или «до одного раза».
• вы можете использовать механизм предварительной выборки, который заставляет клиента извлекать сообщения в память до того, как ваше приложение запросит их.

Answer 2

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

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

Какой тип сценария вы делаете.

Pub / sup или запрос ответа? у вас накапливается временная очередь? Слишком много временных очередей может вызвать проблемы с производительностью. (В основном, когда они задерживаются, потому что вы что-то не закрыли должным образом)

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

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

убедитесь, что вы ЗАКРЫВАЕТЕ, когда закончите. EMS не проясняет ситуацию. Поэтому, если вы устанавливаете соединение и просто закрываете свое приложение, соединение все еще существует и поглощает ресурсы.

проверить вашу терпимость к потерянным сообщениям даже в случае сбоя. Если вы выполняете Client Ack, и не имеет значения, что вы потерпели крах при обработке сообщения, переключитесь на auto. Также я считаю, что если вы используете (TEMS - Tibco EMS для WCF), есть проблема с подтверждением сеанса. Таким образом, сообщение только в том случае, если оно обрабатывается на всем сообщении, мы переключились с Client ACK на тот, на котором был установлен Dups, и он работал лучше)