What steps can be taken to optimize tibco JMS to be more performant?

Question

We are running a high throughput system that utilizes tibco-ems JMS to pass large numbers of messages to and from our main server to our client connections. We've done some statistics and have determined that JMS is the causing a lot of latency. How can we make tibco JMS more performant? Are there any resources that give a good discussion on this topic.

Answer 1

Using non-persistent messages is one option if you don't need persistence. Note that even if you do need persistence, sometimes it's better to use non persistent messages, and in case of a crash perform a different recovery action (like resending all messages)

This is relevant if:

• crashes are rare (as the recovery takes time)
• you can easily detect a crash
• you can handle duplicate messages (you may not know exactly which messages were delivered before the crash

EMS also provides some mechanisms that are persistent, but less bullet proof then classic guaranteed delivery these include:

• instead of "exactly once" message delivery you can use "at least once" or "up to once" delivery.
• you may use the pre-fetch mechanism which causes the client to fetch messages to memory before your application request them.

Answer 2

EMS should not be the bottle neck. I've done testing and we have gotten a shitload of throughput on our server.

You need to try to determine where the bottle neck is. Is the problem in the producer of the message or the consumer. Are messages piling up on the queue.

What type of scenario are you doing.

Pub/sup or request reply? are you having temporary queue pile up. Too many temporary queues can cause performance issues. (Mostly when they linger because you didn't close something properly)

Are you publishing to a topic with durable subscribers if so. Try bridging the topic to queue and reading from those. Durable subscribers can cause a little hiccup in performance too since it needs to track who has copies of all messages.

Ensure that your sending process has one session and multiple calls through that session. Don't open a complete session for each operation. Re-use where possible. Do the same for the consumer.

make sure you CLOSE when you are done. EMS doesn't clear things up. So if you make a connection and just close your app the connection still is there and sucking up resources.

review your tolerance for lost messages in the even of a crash. If you are doing Client ack and it doesn't matter if you crash processing the message then switch to auto. Also I believe if you are using (TEMS - Tibco EMS for WCF) there's a problem with the session acknowledge. So a message is only when its processed on the whole message, we switched from Client ACK to the one that had Dups ok and it worked better)