Tibco EMS performance analysis

Every ten seconds there is a timer triggerred activity of publishing or sending in a loop 8001 messages one by one. 5th and next events are ignored, so we've got 32004 messages. Concurrently we are producing messages of size 16k and 128k (randomly generated body string with 0s and 1s).

There are some cases investigated: durable topic with 2 subscibers, topic bridged with 2 queues and just queues. The measured value is a time between receiving first and last message.

Setting JMS expiration doesn't have big overhead, in message flooding situation it helps.

Topic bridged with 2 queues is way slower than ordinary durable topic with 2 subscribers. Massive messages expiration doesn't cause as big performance hit as receiver consuming large volumes of data. Bridge overhead measured on a queue is 4% (there is JMS selector used in bridge definition).

Now, the most important finding: you should use queues with many sessions. When EMS client is in the process of sending a message, the payload is read directly from socket to memory mapped EMS storage file (you can think of it as a buffer transparently backed by file) and when there is a session interested in this message it is copied directly from buffer to socket (so there is no another read from EMS storage).

CPU is very nicely saturated and the whole process is very efficient.

MaxSessions=1 + ACK=Client preserves order of messages but usage of many sessions in our simple scenario increases throughput by 55%.